GUIs - A Modest Proposal

[Lie Ryan]

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.

> 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).