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 improvements. > 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. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
