GUIs - A Modest Proposal

[Lie Ryan]

On 06/07/10 20:18, Adam Tauno Williams wrote:
> On Mon, 2010-06-07 at 13:19 +1000, Lie Ryan wrote:
>> On 06/07/10 12:18, Adam Tauno Williams wrote:
>>> 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.

binding is part of the programmer-facing API, therefore it's not 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,
> 
> 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.

isn't that my whole point?