On Mon, 2010-06-07 at 13:19 +1000, Lie Ryan wrote: > On 06/07/10 12:18, Adam Tauno Williams wrote: > > On Mon, 2010-06-07 at 11:11 +1000, Lie Ryan wrote: > >> On 06/07/10 10:48, Adam Tauno Williams wrote: > >>> On Sun, 2010-06-06 at 17:03 -0700, AD. wrote: > >>>> On Jun 7, 10:55 am, ant <shi...@uklinux.net> wrote: > >>>>> My concern is simple: I think that Python is doomed to remain a minor > >>>>> language unless we crack this problem. > >>>> I'm curious why you think fragmented GUI choices is a particular > >>>> problem for Python compared to other languages? Or why this is the > >>>> main issue holding Python back? > >>> The base assumption is: there is some core issue holding Python back? > >>> Nah. > >> Any thought about drag-and-drop GUI builder in IDLE? > > Sure; someone should write one, or several. That isn't a toolkit issue. > Sure it is, if it's concerning ease of writing a GUI-based program using > that particular toolkit.
Yes, because the IDE (toolchain) is lacking. Which isn't about the underlying toolkit - both Qt and Gtk provide the ability to load a UI from an XML file. Then the IDE needs to understand relating GUI events to signal handlers in the code. AFAIK, that doesn't exist for Python. However the underlying functionality *does* exist, and work, and has for some time. I can assign a method to an event in Glade - but it is still entirely up to the programmer to create a method with the same name and the correct signature in the correct class - which is entirely automated in Java / .NET IDEs. That is a big deal as applications become larger and more sophisticated, it removes an enormous amount of tedium. <http://www.pygtk.org/articles/pygtk-glade-gui/Creating_a_GUI_using_PyGTK_and_Glade.htm> NOTE: Glade is obsolete, GtkBuilder is the replacement, but I can't find anything on GtkBuilder + Python. > > But then I don't know any of the local Python devs who use IDLE; the > > IDE landscape for Python is very fragmented, which disincentives that > > happening. > I don't use IDLE either, but IDLE comes by default with standard > distribution of python. > >>>> .NET/C# has had preferred GUI APIs come and go and isn't exactly what > >>>> I'd call crossplatform, > >>> Well, if you use Gtk# for your GUI it is probably one of the [if not > >>> "the"] most cross-platform development solution for complex fat-clients. > >>>> Looking at the state of other languages and their GUI toolkit > >>>> landscape, someone might even come to the conclusion that having one > >>>> true GUI toolkit is potentially a bad thing for a language. > >>> +1 In the end the relationships with GUI toolkits is far more about > >>> tool-chain and documentation then it is about language. If there was an > >>> awesome IDE that allowed RAD [of real complex applications] in toolkit X > >>> then people will use toolkit X. [Monodevelop and it's awesome Gtk# > >>> support for Mono/.NET is a good example; the tool makes the toolkit > >>> east to use - people go with the toolkit]. > >> The problem with the current GUI toolkits is their API is designed to be > >> cross-language (i18n). I'd say, keep the current GUI toolkits, make > >> their API easier to use (l10n). > > Which is 'just' an implementation detail. > Why is a GUI toolkit *API* an *implementation detail*? You are missing the point. PyQt, PyGtk, etc.. are wrappers/bindings around Qt, Gtk, etc... respectively. So it *is* an implementation detail of the wrapper/binding to make the API 'pythonic'. Changing class names, rewriting method signatures, adding glue - is a binding issue. > They seems to be > contradictory to me. The simplicity and ease of use of a library depends > on how well-designed their API is, Yea. Which is an implementation detail. > and how "pythonic" the API appears to > a python programmer (unittest, for example, looks more Java-ish than > pythonic). So... improve the binding. That is a really silly reason to develop a new toolkit. -- Adam Tauno Williams <awill...@whitemice.org> LPIC-1, Novell CLA <http://www.whitemiceconsulting.com> OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba -- http://mail.python.org/mailman/listinfo/python-list
