On Jan 20, 10:36 am, rusi <rustompm...@gmail.com> wrote: > On Jan 20, 5:30 pm, Bill Felton <subscripti...@cagttraining.com>
> > With some hesitation, I feel a need to jump in here. > This thread is now at 239 posts (and so I too hesitate...) Why hesitate? Whether it be one post or a million posts, if you have ideas, opinions, or suggestions then by all means jump in and share them. If your words are FUD, not based on fact, or just completely ignorant, don't worry, someone will correct you :-) > The arguments for size, dependencies etc are what may be termed > 'sys-ad' perspectives. The questions of 'it looks nice/ancient etc' > are user issues. What about some programmer perspective? Size is very important. Dependencies are very important (within context!). So too are aesthetics just as important when considering a "graphics" module. In the end, Python should aim to bring the best looking, most advanced (but well tested!), scalable modules we can muster into the stdlib. At the time of it's inclusion Guido believed Tkinter was the best choice -- and i agree with him! However we are talking now about ~20 years of time between then and now. Is anyone so bombastic as to suggest that GUI has not changed significantly in that time. And likewise, is anyone so bombastic as to suggest that the lowly Tkinter module (and even worse TclTk) is representative of 21st century GUI programming? Heck, when Tkinter was added GUIs where just in their infancy as far as popular adoption is concerned! TclTk have lacked vision from the beginning. NEWSFLASH! They did not support themes until version 8.5! (~2009) And they still have much work to do if they ever want to compete with the likes of wxPython however i know thay will never reach that level of sophistication. TclTk as a community are not concerned about keeping up with he times, so be it! However we should not degrade "our" stdlib and "our" community with such backward thinking communities. We must move forward. We must pull our heads out of the sand or mentality will be our undoing. > Using something like VB-in-.NET allows a programmer to put up > significant uis with close to zero coding. Many programmers would > look down on these as 'non-programmers' Well i don't look down on these folks i just feel they are missing out on the richness and abstract thinking that creating the GUI mentally evokes. However. I believe it would be of great benefit to have a graphical GUI builder as part of any GUI package we consider for the stdlib. Do i think it should be IN the stdlib? Probably not due to size. But the fact that it is available for those who would like it to be is great. My biggest complaint with Tkinter is that it lacks so much functionality (even outside the stdlib!) that you really end up wasting your time learning and using it. Because eventually you will be forced to throw away everything you've learned and written and convert to something else. > So the (to me) relevant questions relating to GUIs are for example: > 1. Is glade (and others such) equal to wxpython, tkinter and other > such 'backends'? 2. Can glade (or whichever is the best such tool > today) compare to VB in .NET or does it look like a bad joke in > comparison (I guess the current thing may not be VB but WPF but I > dont want to pretend to know too much about windows) I think we need to add a graphical GUI builder to the list of important attributes of a 21st century GUI library. Not the most important, but still quite important. Especially if we want to "market" Python as a GUI language. And I am not saying we should market Python that way. So the attributes we must demand of a 21st century GUI library are a follows: * Quality Documentation (our problem really) * Cross Platform (their problem) * Rich Full Featured Widget Set. (their problem) * Simplistic API (our problem) * Scalability (their problem) * Accessibility (their problem) * Graphical GUI Builder. (Either or) Also some attributes related to the "Big Picture" of GUI and Python: * Mobile and Web support -- http://mail.python.org/mailman/listinfo/python-list
