[Python-Dev] Event loops, PyOS_InputHook, and Tkinter
"Martin v. Löwis"
martin at v.loewis.de
Thu Nov 10 08:26:51 CET 2005
Michiel Jan Laurens de Hoon wrote:
> At this point, I can't propose a specific modification yet because I
> don't know the reasoning that went behind the original choice of Tk as
> the default GUI toolkit for Python (and hence, I don't know if those
> reasons are still valid today).
I don't know, either, but I guess that it was the only option as a
cross-platform GUI at the time when it was created.
> I can see one disadvantage (using Tk
> limits our options to run an event loop for other Python extensions),
> and I am trying to find out why Tk was deemed more appropriate than
> other GUI toolkits anyway.
I don't think this is a disadvantage: my guess is that other GUI
toolkits share the very same problems. So even though it looks like
a limitation of Tkinter, it really is a fundamental limitation, and
Tk is not any worse than the competitors.
Also, I firmly believe that whatever your event processing
requirements are, that there is a solution that meets all your end-user
needs. That solution would fail the requirement to be easy to implement
for you (IOW, it may take some work).
> So let me rephrase the question: What is the advantage of Tk in
> comparison to other GUI toolkits?
It comes bundled with Python. If this sounds circular: It is. Whatever
the historical reasons for original inclusion where, I'm sure they
are not that important anymore. Today, what matters is that an actual
implementation of a GUI toolkit integration is actively being
maintained, in the Python core. This is something that is not the case
for any other GUI toolkit.
If you think it would be easy to change: it isn't. Somebody would
have to step forward and say "I will maintain it for the next 10
years". Removal of Tkinter would meet strong resistance, so it
would have to be maintained in addition to Tkinter. Nobody has
stepped forward making such an offer. For Tkinter, it's different:
because it *already* is part of Python, various maintainers fix
problems as they find them, and contributors contribute
> Is it Mac availability? More advanced
> widget set? Installation is easier? Portability?
These are all important, yes. But other GUI toolkits likely
have the same properties.
> Switching to a
> different GUI toolkit would break too much existing code?
Most definitely, yes. Switching would not be an option at all.
Another GUI toolkit would have to be an addition, not a replacement.
> I think that
> having the answer to this will stimulate further development of
> alternative GUI toolkits, which may give some future Python version a
> toolkit at least as good as Tk, and one that doesn't interfere with
> Python's event loop capabilities.
I personally don't think so. The task is just too huge for volunteers
to commit to.
More information about the Python-Dev