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. > 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*? They seems to be contradictory to me. The simplicity and ease of use of a library depends on how well-designed their API is, and how "pythonic" the API appears to a python programmer (unittest, for example, looks more Java-ish than pythonic). -- http://mail.python.org/mailman/listinfo/python-list
