GUIs - A Modest Proposal

[rantingrick]

Patches are welcome at any time.  I look forward to seeing your first
contribution.

Kindest regards.

Mark Lawrence.

Hello Mark,

Are you maintaining Tkinter or Tix or both? There is a nagging issue
with Tix that needs fixing. Upon subbclassing some widgets and when
using the import Tix and import Tix as *. Maybe it is already fixed in
3.0 (i have not checked) but we need to fix it.

I am still currently rewriting Tkinter Tix and IDLE in my spare time
but got a bit busy lately. Anyhoo, i would really like to bring some
patches, upgrades, and just a general spit shining to the entire three-
plexx so let me know.

 

[Kevin Walzer]

I get the strong feeling that nobody is really happy with the state of
Python GUIs.

Says who?

Tkinter is not widely liked, but is widely distributed.

I'm a strong advocate of Tkinter--there is very little that it cannot do.

WxPython and

PyGtk are both
powerful, but quirky in different ways. PyQt is tied to one platform.
And there are
dozens more.

Each has its strengths and weaknesses. They reflect the diversity of GUI
programming in general.

Whether or not we like graphics programming, it's not going to go
away. I get the
uneasy feeling whenever I start a new project that there should be a
'better' GUI
than the ones I currently use (WxPython and PyGtk).

That's debatable. These other toolkits have a decade or more of
development behind them. How are you going to improve on them?

Fragmentation is our enemy. Our resources are being dissipated. Is it
not time to
start again? We have shown that it is possible to do the right thing,
by creating Python3.

I'd say no. I used to be frustrated with the range of GUI options for
Python, but the issue was just to get started. I found Tkinter to be
useful for me, I was productive in it, and I have stayed with that.

I ask the group; should we try to create a new GUI for Python, with
the following
properties?:

- Pythonic
- The default GUI (so it replaces Tkinter)
- It has the support of the majority of the Python community
- Simple and obvious to use for simple things
- Comprehensive, for complicated things
- Cross-platform
- Looks good (to be defined)
- As small as possible in its default form

These goals are not all complementary. In fact, some of them, such as
"small" and "comprehensive," are mutually exclusive. Tkinter is pretty
small; people complain it lacks things. PyQt and wxPython are pretty
comprehensive; people complain about their learning curve.

The very diversity of GUI toolkits came into effect because Python is
very easy to extend and integrate with other C/C++ libraries. Writing a
GUI toolkit from scratch is much, much harder. Even a simple toolkit
like Tk has twenty years of developer-hours behind it. Do you really
think the Python community will be able to a) agree on the design of a
new toolkit to replace Tkinter and b) implement the code in a timely
fashion across multiple platforms? It sounds like an impossible goal to me.

--Kevin

 

[ant]

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.

I obviously didn't make my main point clearly enough; I'll restate it
with a different emphasis:
The default GUI shipped with Python is Tkinter.
Few people seem to like it much. This has several consequences.
- It has not blossomed, like Python has.
- There are not hundreds of talented programmers making rapid and
impressive improvements to it.
- Books about Python use it in examples (because it IS the default),
but imply that one should move on.

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

If we are to make progress, I can see two obvious approaches:
1) Improve Tkinter to the point where it is supportable and supported
by a good fraction of Python programmers
or
2) Drop Tkinter as the default and use something else.

If we choose 2) then we have a new set of possibilities:
2a) Use one of the 'major' GUIs, pretty much as is, but presumably
with a lot more people supporting it if it is the default.
2b) Use one of the 'minor' GUIs, and get a lot of people working on it
to make it really good.
2c) Start from scratch. With a project supported by the Community as a
whole, with the agreed objective of being the default.

None of these is easy. All require strong leadership and great
committment.

What surprises me is the apparent willingness of the Python community
to let this issue slide.
I can see that many people have committed to one GUI and want to use
that forever. Fair enough. For the reasons I stated
originally, I've not found one. I think a lot of people deep down are
uneasy about this.

My concern is simple: I think that Python is doomed to remain a minor
language unless we crack this problem.

 

[geremy condra]

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

I obviously didn't make my main point clearly enough; I'll restate it
with a different emphasis:
The default GUI shipped with Python is Tkinter.
Few people seem to like it much. This has several consequences.
- It has not blossomed, like Python has.
- There are not hundreds of talented programmers making rapid and
impressive improvements to it.
- Books about Python use it in examples (because it IS the default),
but imply that one should move on.

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

If we are to make progress, I can see two obvious approaches:
1) Improve Tkinter to the point where it is supportable and supported
by a good fraction of Python programmers
or
2) Drop Tkinter as the default and use something else.

If we choose 2) then we have a new set of possibilities:
2a) Use one of the 'major' GUIs, pretty much as is, but presumably
with a lot more people supporting it if it is the default.
2b) Use one of the 'minor' GUIs, and get a lot of people working on it
to make it really good.
2c) Start from scratch. With a project supported by the Community as a
whole, with the agreed objective of being the default.

None of these is easy. All require strong leadership and great
committment.

I take it you're volunteering?

Geremy Condra

 

[AD.]

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?

As far as I can tell, most of the other cross platform dynamic open
source languages (eg Perl, Ruby, PHP, Javascript) face the same
problem or don't even include a GUI toolkit. The one exception I can
think of that has a non-fragmented native GUI option is Tcl (which
being Tk is slightly ironic here), but it hasn't stopped Tcl being
doomed to be a much more minor language than Python is.

..NET/C# has had preferred GUI APIs come and go and isn't exactly what
I'd call crossplatform, Java has had (and still does?) multiple
toolkits, C/C++ never included any to begin with.

Objective C has an obvious native GUI choice, but it's not at all
crossplatform and is about as 'minor' a language as Python is anyway.
Legacy VB and Delphi had built in GUIs but they weren't really cross
platform and seem to be slipping out of relevance.

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.

I don't do any GUI coding so I don't have any toolkit preferences
myself, but I think the only sane way to address your concerns is to
incrementally improve Tkinter. Coming up with a new toolkit from
scratch is insanity, and switching the toolkit to something else
doesn't actually help much (ie you don't think any are currently
suitable anyway) and is just as likely to annoy other people.

 

[Adam Tauno Williams]

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]

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

 

[Lie Ryan]

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.

 

[Adam Tauno Williams]

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

 

[Lie Ryan]

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

 

[Carl Banks]

I get the strong feeling that nobody is really happy with the state of
Python GUIs.
Tkinter is not widely liked, but is widely distributed. WxPython and
PyGtk are both
powerful, but quirky in different ways. PyQt is tied to one platform.
And there are
dozens more.

Whether or not we like graphics programming, it's not going to go
away. I get the
uneasy feeling whenever I start a new project that there should be a
'better' GUI
than the ones I currently use (WxPython and PyGtk).

Fragmentation is our enemy. Our resources are being dissipated. Is it
not time to
start again? We have shown that it is possible to do the right thing,
by creating Python3.

I ask the group; should we try to create a new GUI for Python, with
the following
properties?:

- Pythonic
- The default GUI (so it replaces Tkinter)
- It has the support of the majority of the Python community
- Simple and obvious to use for simple things
- Comprehensive, for complicated things
- Cross-platform
- Looks good (to be defined)
- As small as possible in its default form

If so, what are the next steps?

The Python SIG on GUIs closed years ago. Should that be revived?

This is "A Modest Proposal" (J. Swift). In a sense, I am suggesting
that
we eat our own babies.

But don't we owe it to the community?

Speaking for myself, PySide has resolved this issue for me. I used
PyQt for some things but didn't want to use it for everything because
of the license, but I'd be ok to use PySide for anything. It's
portable to the major systems and generally better (IMHO) than the
other toolkits.


Carl Banks

 

[Aahz]

My concern is simple: I think that Python is doomed to remain a minor
language unless we crack this problem.

Where's your proof that Python is a minor language?

 

[Carl Banks]

I obviously didn't make my main point clearly enough;

I think you did make your point clearly enough, it's just that not
many agreed with you. But I'll play along.

I'll restate it
with a different emphasis:
The default GUI shipped with Python is Tkinter.
Few people seem to like it much. This has several consequences.
- It has not blossomed, like Python has.
- There are not hundreds of talented programmers making rapid and
impressive improvements to it.
- Books about Python use it in examples (because it IS the default),
but imply that one should move on.

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

GUI programming is too complex for us (i.e., mankind) to have reached
any condition where One Obvious Way makes sense, we just don't know
enough, and there might not ever be one.

So it would be foolish for Python to go out and say "this is the One
Obvious Way"--it'd be like claiming to be smarter than mankind.

Right now the best way is to let GUI toolkits be toolkits and to
compete with each other.

If we are to make progress, I can see two obvious approaches:
1) Improve Tkinter to the point where it is supportable and supported
by a good fraction of Python programmers
or
2) Drop Tkinter as the default and use something else.

If we choose 2) then we have a new set of possibilities:
2a) Use one of the 'major' GUIs, pretty much as is, but presumably
with a lot more people supporting it if it is the default.
2b) Use one of the 'minor' GUIs, and get a lot of people working on it
to make it really good.
2c) Start from scratch. With a project supported by the Community as a
whole, with the agreed objective of being the default.

I believe choosing any one of these options would do far more harm
than good.

The bureaucracy of the standard library works to keep Python headed
down the straight path for stable, mature tasks like basic
networking. But for dynamic, complex, cutting-edge tasks like GUI
programming it would bog everything down. Only straightforward,
simple GUIs like Tkinter are suitable for the standard library.

None of these is easy. All require strong leadership and great
committment.

Strong leaders in GUI programming are best left unhindered by the
constraints of Python's standard library process.

BTW, what's your plan for producing such a leader? Because if we
don't have a leader it's kind of a moot point. (I know some people
asked you to volunteer, but I suspect you would agree that you're not
up to the task, so I assume you are merely a visionary and have
someone lined up that you've somehow convince to do the dirty work of
leadership.)

What surprises me is the apparent willingness of the Python community
to let this issue slide.

It's not a willingness to let the issue slide; it's disagreement that
it's an issue at all.

I can see that many people have committed to one GUI and want to use
that forever. Fair enough. For the reasons I stated
originally, I've not found one. I think a lot of people deep down are
uneasy about this.

I haven't noticed much of that. The main objection seems to be that
Python carries around the dead weight of Tkinter, or at least that
it's basic GUI isn't actually written in Python.

I've seen a lot more people clamoring for a web framework a la Ruby on
Rails, mostly, I suspect, out of greed for exposure. Same issue,
though.

Notice that Ruby got typecast as a web language. Then people started
jumping off the RoR bandwagon, so now it's a web language with few
users. You want that for Python? I don't.

My concern is simple: I think that Python is doomed to remain a minor
language unless we crack this problem.

Well, if Python is considered a "minor language" now, I'd happy to
welcome that particular damnation.

-1


Carl Banks

 

[ant]

I rather feel like I'm flogging a dead horse here, but time for
another mile...

First off, I'm not volunteering to lead this effort. I don't think
anyone should
even think about that until and unless the Python Powers That Be
actually
decide that it is worth doing. That is what I meant by 'strong
leadership'.

Second; 'A minor programming language'. According to

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Visual Basic is more popular than Python. That makes me feel that
there
is something wrong with the world.

Third: "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? "
It's not a particular problem for Python compared to other languages.
It's a general problem for all programming languages. But I presume
that you read this newgroup because you think Python is in some sense
'better' than other programming languages. And I think we can make it
better still.

Fourth: " BTW, what's your plan for producing such a leader? Because
if we
don't have a leader it's kind of a moot point. (I know some people
asked you to volunteer, but I suspect you would agree that you're
not
up to the task, so I assume you are merely a visionary and have
someone lined up that you've somehow convince to do the dirty work
of
leadership.) "
I'm not a visionary and I don't have someone lined up. And I am
certainly
not up to the task myself. But I have watched with interest the
process of
turning Python2.x into Python3.x. Does that give any hints about who
I
think should be considering this topic (see first point)?

 

[Nobody]

If we are to make progress, I can see two obvious approaches:
1) Improve Tkinter to the point where it is supportable and supported
by a good fraction of Python programmers
or
2) Drop Tkinter as the default and use something else.

You forgot:

3) Drop Tkinter and don't provide any GUI toolkit as part of the standard
library.

It seems to have worked out okay for C and C++.

 

[Adam Tauno Williams]

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.

 

[Simon Hibbs]

If we are to make progress, I can see two obvious approaches:
1) Improve Tkinter to the point where it is supportable and supported
by a good fraction of Python programmers
or
2) Drop Tkinter as the default and use something else.

IIRC Guido has ruled out officialy adopting a full-bore GUI toolkit
such as WxPython or PyQT, or even a supercharged verison of Tkinter,
into the standard library. There are two main reasons. One is that
doing so would more than double the standard Python distribution's
disk footprint, to no advantage for non-graphical target systems or
developers wanting to use native GUI APIs. Another is that it wouldn't
make any of the other options go away, so e.g. if PyQT were chosen,
anyone wanting to use WxPython would have to install it as well,
creating even more bloat.

GUI toolkits are major projects with their own development cycles and
roadmaps that may not match with that of the standard library. They
are also still rapidly evolving. The standard library should only
contain stable, mature code bases. Furthermore the core Python dev
team have limited resources. Increasing the officialy maintained code
base by 2x or more just isn't supportable.

Tkinter is perfectly adequate for basic GUIs. If you want something
more sophisticated there are plently of high quality, well documented
alternatives to match your platform or functionality requirements.

Simon Hibbs

 

[Steven D'Aprano]

First off, I'm not volunteering to lead this effort. I don't think
anyone should
even think about that until and unless the Python Powers That Be
actually
decide that it is worth doing. That is what I meant by 'strong
leadership'.

You have the process backwards there. The Python-Dev team isn't going to
push one GUI toolkit as the One True Toolkit unless the wider community
standardises on it first.

Consider the plight of the Python developers. They're an all-volunteer
effort, and although a handful of them are partially funded by the PSF or
other companies like Google, they're still chronically undermanned and
overworked. Just go and look at the bug tracker and see how many bugs
languish for want of somebody to work on them. The last thing they're
going to do is take on a project of the magnitude of creating a new GUI
toolkit. A full-featured toolkit is a project at least as big as the rest
of Python plus the standard library, and probably bigger. You're asking
them to double their work load to suit your aesthetic judgement that none
of the existing toolkits are good enough.


[...]

Third: "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? "
It's not a particular problem for Python compared to other languages.
It's a general problem for all programming languages.

I don't see why you think so. Well, Apple believes so, and twenty years
ago I agreed with them, but having looked at how Macintosh and it's
consistent look-and-feel has repeatedly failed to set the world alight
against Windows and its multitude of inconsistent GUIs, I'm no longer
convinced by Steve Jobs' argument.

It's 2010 and despite all of Apple's marketing, design excellence and
consumer mindshare, their share of the PC market is still about the same
as it was in the mid-80s and well under their peak of 12% in 1993.
(Depending on who is doing the reporting and how they calculate the
numbers, Apple Macintosh has anything from 3% to 8% market share, not
that much better than Linux at 1-2%. And the Linux figure is for sales,
not installations).

It seems to me that a consistent, best-of-breed look-and-feel is good for
creating a brand, but flexibility and choice is good for capturing a
market.

Consistency carries it's own dangers, and what you call "fragmentation"
simply means that GUI toolkits exist in a free market of ideas rather
than a centrally-planned monopoly. For idiots^W those who like Gnome,
there is PyGTK; for those who prefer their window manager to be
perpetually in pre-beta, there is PyKDE; if you like QT, there is PyQt;
if you have no aesthetic sense at all, there is tkinter; if you have a
hankering for the Good Old Days programming in Hypercard on a Mac SE,
there is Pythoncard; if you've drunk the corporate Koolaid, there are
Jython and IronPython with their own GUI widgets; if you want the choice
of developing for the desktop or the web, you might choose Pyjamas; and
so on.

There is, hopefully, a GUI toolkit for everyone, and no best-of-breed
because people will never agree on what best-of-breed would mean. You
call this fragmentation -- I call it freedom of choice.

 

[Mark Lawrence]

Hello Mark,

Are you maintaining Tkinter or Tix or both? There is a nagging issue
with Tix that needs fixing. Upon subbclassing some widgets and when
using the import Tix and import Tix as *. Maybe it is already fixed in
3.0 (i have not checked) but we need to fix it.

I am still currently rewriting Tkinter Tix and IDLE in my spare time
but got a bit busy lately. Anyhoo, i would really like to bring some
patches, upgrades, and just a general spit shining to the entire three-
plexx so let me know.

I don't maintain either, I'm looking forward to seeing you do it.

Regards.

Mark Lawrence.

 

[python]

Ant,

Have you checked out the Dabo framework? Dabo provides a set of tools
and underlying framework that makes VB style GUI development possible
using Python.

Dabo is designed to be GUI framework independent however it currently
only supports wxPython.

Dabo has a very friendly and helpful mailing list if you want to give it
a try.

Dabo can be found here:
http://dabodev.org

Malcolm