GUIs - A Modest Proposal
in [Python]
|
From: Adam Tauno Williams on 6 Jun 2010 20:48 On Sun, 2010-06-06 at 17:03 -0700, AD. wrote: > On Jun 7, 10:55 am, ant <shi...(a)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. > .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]. -- Adam Tauno Williams <awilliam(a)whitemice.org> LPIC-1, Novell CLA <http://www.whitemiceconsulting.com> OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba
From: Adam Tauno Williams on 6 Jun 2010 20:52 On Sun, 2010-06-06 at 15:55 -0700, ant wrote: > On Jun 6, 2:22 pm, ant <shi...(a)uklinux.net> wrote: > > I get the strong feeling that nobody is really happy with the state of > > Python GUIs. > <snip...> > What an interesting set of responses I got! > And - even more interesting - how few of them actually seem to think > there is a problem, let > alone make any attempt to move the situation forward. > I appreciate that there are proponents of many different GUIs. I am > asking that all step back > from their particular interests and - for example - try to see the > situation from the viewpoint of > - say - a Python newbie, or an organisation that is thinking of > switching from (example only!) Visual Basic. Taking a step back ^H ... Hmmmm... yep, no issue here. > The result that our hypothetical new recruit has to make a choice for > the new, big project. Remember that > GUIs have hundreds (sometimes thousands) of classes, functions and > constants. Let alone idioms and design > patterns. Yes - this is the natural and *unavoidable* consequence of "comprehensive". "Those who do not reuse, are doomed to reinvent." And reinvention includes rediscovering the exact same problems. > That is what I meant by 'Our resources are being > dissipated'; the effort of learning, remembering > and relearning a workable subset of these is substantial. > So it would be good to be able to use One Right Way, not try several > (as I have - I will admit I didn't try PyQt; > GUI fatigue was setting in by then). This isn't a language issue; it is a tool-chain issue. Get a better IDE. -- Adam Tauno Williams <awilliam(a)whitemice.org> LPIC-1, Novell CLA <http://www.whitemiceconsulting.com> OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba
From: Lie Ryan on 6 Jun 2010 21:11 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...(a)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? >> .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). In other words, current GUI API can be used everywhere (IOW, their API works well accross many languages); but all those GUI API also feels foreign everywhere (IOW, their API always feels like borrowed from another language). To abuse the language, i18n goal is already achieved, l10n is not met yet.
From: Adam Tauno Williams on 6 Jun 2010 22:18 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...(a)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. 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. > >> .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. Comparing early Gtk# implementations with current ones - they did a significant amount of work to make Gtk# more .NET-ish, without rewriting Gtk. [And PyGtk is hardly neglected; significant features of GNOME 3 such as Zeitgeist are Python apps <http://live.gnome.org/Zeitgeist>]. I haven't had a chance to play with it but <http://python-forum.org/pythonforum/viewtopic.php?f=2&t=9415> looks encouraging. But that is still far from the depth of functionality available in .NET and Java toolchains [which, again, has nothing to do with the specific widget set]. -- Adam Tauno Williams <awilliam(a)whitemice.org> LPIC-1, Novell CLA <http://www.whitemiceconsulting.com> OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba
From: Lie Ryan on 6 Jun 2010 23:19
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...(a)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). |