From: Adam Tauno Williams on
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
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
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
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
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).