[Python-3000] back with more GUI planning in a few days...

[Paul Boddie]

Talin wrote:
> 
> There are two reasons why I think that bundling a GUI library with
> Python is a good idea:
> 
>   -- It makes it possible to include GUI-based tools and applications
> in the base distribution.

I agree with this, although how ambitious are such tools? If you're just 
popping a dialogue asking for user input, there are typically other means of 
doing that without bringing in a whole GUI framework.

>   -- By reducing the dependency on downloading and installing
> a UI framework, it lowers the friction for developing small, one-off
> UI tools. This is not so much an issue with large apps, since the
> cost of choosing and installing the optimal UI package is small
> compared to the development cost of the project. But for small
> tools (for example, a configuration control panel), the extra step
> of installing a UI framework may be significant.

I think the reduced friction is less about the installation and a lot more to 
do with which API you use: this being a point that the Web frameworks debate 
still hasn't caught up with. In other words, given that whichever toolkit is 
likely to be a click-install away, you're likely to be spending more time 
looking up how to write the GUI code, and a standard in this domain hopefully 
makes such work a lot more obvious. Scaling a standard up to complicated, 
integrated applications is a mostly unsolved problem, though.

> However, there are some significant obstacles to be overcome before
> this can happen.
> 
> First, there's no such thing as a "simple" UI toolkit. Certainly, some
> toolkits are simpler than others. But as I have argued before, UIs are
> a language, and that language has evolved over time, to the point
> where it has a rich vocabulary of appearances and behaviors.

True. And the more complicated applications become, the more likely it is that 
you'll want to consider other things, such as the environment in which the 
applications operate. Opening a special toolkit file chooser dialogue may be 
acceptable for some kinds of applications, but together with other "platform 
agnostic" features it can also provide a huge disincentive to use those 
applications. (Personally, I dislike the Gtk+ and GNOME file choosers, partly 
because they have been ruined by usability "experts" with nostalgia for 
NeXTStep, but I really dislike them when they pop up in KDE, especially since 
KDE applications and the environment generally provide better solutions.)

In fact, this topic conveniently highlights an issue I see with the way this 
and other topics are approached by parts of the Python community. In this 
community, the attitude to something like cross-platform user interfaces 
often involves glossing over the diversity of actual environments in favour 
of having something that does the job passably, often manifesting itself in 
some people's interpretation of what support for Linux or UNIX actually is: 
"Gtk+ support covers Linux, right?" Unfortunately, despite noise from various 
desktop environment proponents, the real world is a lot more complicated and 
a lot more interesting; neglecting this reality causes the kind of 
frustration and disenchantment described above.

People in this community often used to point at Java and claim how 
isolationist the technology was (and largely still is), how Java user 
interfaces were so unlike the environments they run in, how Java has so many 
poor abstractions for system functionality that get in the way, and how 
Python seems to encourage cooperation and integration with the environment. 
However, parts of the Python community seem to behave like Java technology: 
preferring to abstract away diversity, isolating "Pythonic" solutions from 
the outside world, looking inside itself for solutions to problems that 
others have already solved.

Indeed, the wider Python community should be more aware and more willing to 
work with other communities. For example, Python already works well with both 
KDE and GNOME, and there is an increasing (if arguably belated) interest in 
dynamic languages in the communities around those environments. Instead of 
pretending that Python somehow doesn't need those technologies to be 
successful or important (perhaps related to the sentiment that "I use 
Windows/Mac and don't care about anything else"), perhaps a mutual 
recognition in each community of the other would be beneficial. None of this 
provides a simple answer to the question, "How do I write a complicated, 
integrated, cross-platform GUI application in Python?" However, we shouldn't 
seek to mislead by providing simple answers where in practice there are none. 
And given that people actively working on such issues don't have simple 
answers to such questions, we shouldn't be dishonest in pretending we have 
something they don't.

> (One of my concerns about PyGUI is that the postings by its
> proponents on this list seem to be somewhat dismissive of this
> point - in other words, I get the impression that faced with the
> complex vocabularity of UI designs, they would rather simplify
> the visual language than deal with its full complexity. I understand
> the motivation for doing so - as engineers, we all want to make
> things simpler - but I think that in this case it ignores some
> important realities about user and programmer expectations.)

PyGUI looks like an interesting project: who wouldn't want to gloss over the 
implementation detail of different and potentially unfamiliar GUI 
environments? And I'm a big fan of putting layers on top of what seems like 
needless inconsistency. But really, I think that people need to think back to 
what the situation was like before: first there was stdwin, then there was a 
cornucopia of different solutions (Xlib and Motif bindings, for instance), 
and eventually Tkinter made it in as the binding to arguably the only open 
source, cross-platform toolkit available at the time. I suppose that 
supporting stdwin in the face of better toolkits and increased demand for 
better native behaviour was just too much work, and I doubt that these 
factors have diminished in the ten or more years since it was abandoned. 
Promoting a successor to stdwin doesn't seem like progress to me.

Paul