GUIs - A Modest Proposal

[Adam Tauno Williams]

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... at 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 <awilliam at whitemice.org> LPIC-1, Novell CLA
<http://www.whitemiceconsulting.com>
OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba