What is better tkinter or wxpython

Cons: Non-native look-and-feel. Simplistic model is easy to learn, but becomes cumbersome with complex interfaces. To be truly usable, requires downloading extra toolkits PMW for example. Probably a dead-end technology, as toolkits such as wxPython gain mindshare.

Very flexible. Requires downloading and installing not included with Python. Once you start using it, you'll find yourself evangelizing as much as you program ; And Again by Cliff: Yes, with wxPython you pay the price up front, in the learning curve.

With Tk you pay it later, when you're developing applications with real interface requirements. We use wxDesigner. The resulting applications loaded and appeared much more quickly at least under MSW , presumably due to the native implementation details. There's a great store of usage examples in the wxPython demo thanks to Robin Dunn et. While not a substitute for written documentation, I'd rather examine working code than pour over a tome to do this any day!

The users group is one of the most attentive, responsive and helpful communities I've ever run across on the net, and the signal to noise ratio has remained quite high over the time that I've been following it. Kudos to all of you, and particularly to Robin, who is just phenomenal! There was also a consensus that the "native Tk look" was being done through some native work and some work within the library to make things look right.

No other toolkit provides the same mix of ease and power than those two widgets in my experience. Uses native widgets on the mac and windows. Tk is rock solid with few cross-platform idiosyncrasies. I think Tkinter's binding mechanism is far superior to wxPython's; it's more flexible and consistent.

I think Tkinter's three geometry managers - pack, place and grid - are much more powerful and easy to use than the wxPython sizers.

Sometimes hard to debug in that Tkinter widgets at their core aren't python objects; tkinter provides a wrapper around the actual tk widgets which sometimes means you get weird error messages. There is very little printing support you can generate postscript docs from the canvas, but there's no built-in support in the text widget for printing.

Some people claim Tk is ugly. Tkinter isn't as "pythonic" as wxPython. Documentation is very weak in my opinion; it's very hard to find specific information. I've seen wxPython crash and print assertions way more often than Tkinter. Stack Overflow for Teams — Collaborate and share knowledge with a private group.

Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. Pros and cons of tkinter and wxWidgets? Ask Question. 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.

Managing the parallel hierarchies of sizers and windows adds complexity without a lot of additional functionality - in that delightful 's object-oriented way that seemed like such a good idea to all of us at the time. 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. 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:.

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.