DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workkloads.

Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Start Coding With Google Cloud Workstations
  • Beyond ChatGPT, AI Reasoning 2.0: Engineering AI Models With Human-Like Reasoning
  • Why I Started Using Dependency Injection in Python
  • Reinforcement Learning for AI Agent Development: Implementing Multi-Agent Systems

Trending

  • Hybrid Cloud vs Multi-Cloud: Choosing the Right Strategy for AI Scalability and Security
  • Apache Doris vs Elasticsearch: An In-Depth Comparative Analysis
  • How to Practice TDD With Kotlin
  • While Performing Dependency Selection, I Avoid the Loss Of Sleep From Node.js Libraries' Dangers
  1. DZone
  2. Coding
  3. Languages
  4. Python GUI Programming: wxPython vs. tkinter

Python GUI Programming: wxPython vs. tkinter

The author compares wxPython to tkinter for ease of use and performance differences while trying to overcome his own biases

By 
Tom Radcliffe user avatar
Tom Radcliffe
·
Oct. 15, 15 · Tutorial
Likes (2)
Comment
Save
Tweet
Share
15.5K Views

Join the DZone community and get the full member experience.

Join For Free

Even though the Tcl/Tk-based UI module called tkinter is a fairly standard part of the Python distribution and has been for ages, it often gets ignored by developers who have come to Python from other directions.

My own background is mostly in the C/C++ world, where I had deep experience with Qt and wxWidgets. That made it natural and easy to focus on wxPython when I started using Python ten years ago. I knew tkinter existed, but didn't pay it much attention.

I thought Tcl/Tk was old, odd, and obscure, which turns out not to be the best technical judgment I've ever made.

In modern Tcl/Tk, tkinter is simple, powerful, and fast. It looks pretty good too. Modern Tk includes a styling mechanism via themed widgets that allow it to be made even prettier.

Comparing wxPython and tkinter

Comparing wxPython and tkinter using basic examples we get a sense of what they look like, in code and on-screen. I don't mean to knock wxPython, which is powerful, well-documented, and has been my go-to Python UI solution for many years. But tkinter has some features I really like, particularly the way it handles layout management.

Here are screenshots of two similar examples, one using tkinter (taken from: http://www.tkdocs.com/tutorial/grid.html), one using wxPython (slightly modified from: http://zetcode.com/wxpython/layout/):

Python tkinterwxPython

They have comparable controls and layouts. The wxPython version is 76 lines and the tkinter version is 48 lines, most of which is accounted for by layout code.

The wxPython example uses nested HBOX and VBOX sizers, which is my preferred way to handle layout using that toolkit because I find it easier to reason about, and therefore, easier to maintain and modify. The tkinter example uses a grid layout, and this does account for some of the difference in program length. However, it also points to quite a different design choice between the two toolkits: wxPython externalizes the layout classes in its sizer hierarchy, whereas tkinter internalizes layout so that each widget manages its own children using a variety of policies, of which grid is just one.

UI layout in wxPython is not a lot of fun, and I've never found GUI builders - from DialogBlocks to BoaConstructor and beyond - to be much help. Managing the parallel hierarchies of sizers and windows adds complexity without a lot of additional functionality - in that delightful 1990's object-oriented way that seemed like such a good idea to all of us at the time.

tkinter does away with all that by hiding layout policy behind the widget interface. You just add children to their parent's grid. You don't have to create the grid sizer, add the children to it, and then set it as the sizer on the parent. This inevitably creates a bunch of names like "gridSizer1" along the way that you'll regret when it comes time to edit the UI code.

Then there is the speed comparison. For example, how long does it take from typing python myapp.py at the command prompt to the UI being shown on the screen? The difference is negligible on a desktop machine, but on a little embedded ARM processor the wall-clock seconds for these simple example programs come out like this:

wxPython: 6 seconds

tkinter: 1 second

It wasn't the world's most sophisticated test--I just used my watch for the timings--but the difference is so big it doesn't have to be. The canonical absolute response time that users are willing to tolerate is 2 seconds, going from three times that to less than half is kind of a big deal.

I've done a lot of embedded work over the years, and even got wxX11 to compile on an ARM board that has almost as much computing power as a toaster. The C++ version is fast enough that users don't experience perceptible lag. I've run some wxPython-based tools on the same system (maintenance scripts for field engineers, who will tolerate anything) and have always been disappointed at how slow they were. I would love to re-write the main application UI in Python and let C++ do all the low-level stuff underneath, but it just didn't seem practical given even wxGTK/C++ was unacceptably slow on that board.

I've looked at a lot of different toolkits for embedded UI over the years: Qt Embedded, GTK and GTK+, FLTK, and so on. None of them met the criteria of power, maturity, i18n/l10n, and speed that I needed for embedded systems running on boards in the "Raspberry Pi or a bit smaller" category.

Now, I feel like the search may be over, and the solution was right under my nose the whole time. I just never paid attention to it because of an outdated and incorrect attitude toward Tcl/Tk and tkinter.

NOTE: In modern Python the old Tkinter module has been renamed tkinter, and the ttk module has become a submodule of it, so when legacy code did from Tkinter import * and import ttk, modern (Python 3) code will do from tkinter import * and import tkinter.ttk. Also, if you get an error on these imports saying the module _tkinter could not be loaded, your Python install can't find _tkinter.so or equivalent on its LD_LIBRARY_PATH or equivalent, which may be an issue with your environment settings or a problem with your Python build. I had to build Python 2.7.10 from scratch on ARM and then do some fiddling to get _tkinter.so to build. Watch out for error messages during the build and note that tkinter is built as part of "make install" not "make", at least on Linux. The build can have trouble finding the Tcl and Tk headers and shared libs if your paths aren't set correctly Setting CPPFLAGS, LDFLAGS and LD_LIBRARY_PATH as described in the answer to this question on Stackoverflow may help.

Python (language)

Published at DZone with permission of Tom Radcliffe. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Start Coding With Google Cloud Workstations
  • Beyond ChatGPT, AI Reasoning 2.0: Engineering AI Models With Human-Like Reasoning
  • Why I Started Using Dependency Injection in Python
  • Reinforcement Learning for AI Agent Development: Implementing Multi-Agent Systems

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!