Hacker News Reader

Comment by witty_username | Hacker News Reader

Tk is just too old and bad. It doesn't support Unicode rendering properly of a lot of characters and lacks a lot of features of any modern GUI toolkit like Qt or GTK.

View on HN

True... but the crazy thing is the other options aren't hugely better. GTK has poor OSX support, while QT is massive and the bindings situation is still unclear - it's workable for building an app, but would you want to have it included in the default install? Kivy is neat but comparatively immature and doesn't have native theming. WxWidgets can look good but doesn't seem to have Python3 support.

I was really surprised by this actually - I wanted to create some simple GUI apps and assumed there would be something clean, small, and modern to replace TK... but nope. And all the documentation (including for python tk) is pretty terrible. The most realistic suggestion I've seen is... write you GUI in HTML and Javascript and use python for the backend server. Not a great situation when the best way to write a good looking GUI for Python is basically not to use Python...

https://github.com/pybee/toga

IMHO, it's rather amazing, though it needs to be developed further, to support more widgets, remove bugs, etc. Sadly it did not gain much traction after release. Maybe due to not comprehensive documentation and few nasty bugs in the beginning.

I would give this library a go if I would be developing GUI application in python, though apart making few exercises, I have not used it a lot.

Major pros, that it's in python, so debugging is easy, and what is not covered with documentation, can be uncovered also. Another thing you can simply install it with pip.

>GTK has poor OSX support

Is it really that bad ?

I was really impressed the last time I did GTK+ (was a linux app small content pipeline frontend for designers) at how fast I got things done, the docs were simple and to the point [1], Glade was buggy but still usable (I had to reload after some time because it would get progressively slower as I would add/remove elements - probably a leak somewhere) I got an app with complex tree view/table/filtering etc. running within two days from 0 previous GTK+ experience.

I liked that it was a straight GUI toolkit - reminded me of VB - just create GUI elements with RAD tool and hook up callbacks in good old python - no fancy MVC, IOT learning QML and w/e. - exactly the kind of thing that lets you do apps of this size fast IMO.

[1] https://python-gtk-3-tutorial.readthedocs.org/en/latest/

From what I could see, the Quartz backend isn't complete, and generally Mac doesn't seem to be a high priority. Some apps like Inkscape still require to install X11 for mac (which is slow, and makes for a very clunky ux), except for experimental builds with GTK native. In short, not really a plug-and-play experience.

A Qt IDE would be fine. Sure it is rather large - something like 30 MB unzipped for a "Hello world" using QML, though 20 MB of that is Unicode data which can be cut down, and non-QML apps are smaller. But it's much nicer than Qt.

The IDE doesn't have to be written in Python (e.g. PyCharm isn't and that is probably the best Python IDE available at the moment).

In the sentence "But it's much nicer than Qt.", what does "it" refer to?

Ooops that was a typo. Probably should have said GTK (or TK).

QML?

That matches my experiences when I was looking at desktop GUI toolkits for another project. I understand it though given most things are web or mobile these days.

A recent poll I had on the TkDocs site showed documentation is definitely the big issue for what people are trying to accomplish with Tk.

> while QT is massive and the bindings situation is still unclear - it's workable for building an app, but would you want to have it included in the default install?

Qt's like < 50 M. We aren't living in 1995. It's bindings aren't just "workable"; they are pretty good.

I think Tk is entirely reasonable for the types of "utility" applications that people are primarily using it for; nobody is going to start writing a flashy new cutting edge app in it today.

For those with legacy code or other constraints where it makes sense, the TkDocs site is all about getting the most out of Tk by documenting the newer pieces that people likely haven't seen.

IDLE itself is in that category of using Tk by constraint. There have been multiple forks of it, sometimes using alternate GUI toolkits. But for it to stay as part of the Python standard library, it has to only depend on other things that are part of the standard library. Which for GUI stuff, means Tkinter. And having it built into Python is a very big deal for a lot of people teaching Python, which is the main target audience.

Tk is not just "bad"; putting lots of text into Tk freezes it, lack of Unicode support, multiple modern widgets are missing.

It has the advantage of being simple. As other commenters have pointed out, there's not really a good, simple, modern, cross-platform GUI library with Python bindings. As you can observe from how slick Jupyter is getting in comparison, we've almost given up on improving native GUI toolkits in favor of using the browser. At least Tk doesn't force you to use the Motif widgets any more!

Are you forgetting about PyQt and PySide? If they don't meet the requirements for "good, simple, modern, cross-platform GUI library," then I'm hard pressed to think of a library or binding for any language that will.

I guess I could see a sticking point on "simple" but IMO it's significantly easier to create a GUI using PyQt than it would be to mess with web servers and HTML to create a web based UI.

Exactly the opposite --- I work with Qt in Python, and I've used both PyQt and PySide. I assure you it's not simple. Not that that's bad. It's a flexible and powerful tool. But using it doesn't feel like Python. It feels like C++ with Python syntax. No surprise, since Qt is written in C++.

You've got a point in that web-based UIs aren't any simpler. Jupyter is a project of impressive sophistication and hard work by all involved. Really what I'm complaining about is that the move toward web-based UI has starved native GUI toolkits of interest.

> I assure you it's not simple.

I have to disagree. I've written GUIs in Qt/C++, PyQt, MFC (a long time ago), Perl/Tk, and even ltk/Common Lisp, and PyQt is the easiest of them all. There's definitely some C++ showing through in spots, but it's well hidden in most situations.

> Really what I'm complaining about is that the move toward web-based UI has starved native GUI toolkits of interest.

I have to agree with that. Most languages are lucky to have any native GUI toolkit bindings at all.

IMO PyQt is pretty much like Python; the C++ parts show up in places but otherwise it's WAY simpler than Tk's complexity to do even basic stuff and horrible themeing on Linux. I used Tk a bit once; the Tcl parts show up quite a bit and it's generally very hard to use compared to Qt Designer or any other modern toolkit's tools.

"Tk is just too old and bad."

Tend to agree, funny thing though, I can use it on various versions of Win/Mac/Lin OS. The secret to Python IDLE is it just works as predicted since it came out. A clever choice of GUI.

Reply on news.ycombinator.com