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

[Talin]

Bill Janssen <janssen <at> parc.com> writes:

> Folks, I've got a paper deadline looming, and helpful as this
> discussion has been in my procrastination , I need to get back to it.
> I'll take this thread up again next week, if no one else does.
> 
> Please feel free to send me mail in the meantime, and try a few things
> with PyGUI -- let's see if it's as capable as I think it is, and
> what's missing.
> 
> Bill

I am generally supportive of the idea of having a "standard" GUI in
Python 3000, but any such framework should prove it's merit in the
competitive arena of application development before being
"blessed" with official status.

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.

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

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.

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

The result is that any UI framework is going to be a large
undertaking, and there's no way around that. I know that as
a UI programmer myself, I tend to be extremely particular about
small details, and I would be hesitant to use any UI toolkit
that doesn't address those details.

Another issue is one of community acceptance. I strongly feel
that it should be the "market" of Python programmers that chooses
the UI solution, not the core developers. I approve of the decision
criteria which allowed ElementTree to become part of the standard
lib: It wasn't because ElementTree has a simple and powerful design;
it was because ElementTree has a simple and powerful design *and*
is already in widespread use. I think that a UI toolkit should have
to meet the same criteria.

Now, the good news is that there's plenty of time. Py3k isn't coming
out any time soon; If PyGUI truly is a better solution, it will have
enough time to gain the market share that it needs to meet the
criteria for inclusion.

Now, I am sure that the developers of PyGUI realize that there's
more to gaining market share than technical excellence. But I
would suggest that there are many things that they themselves
can do to foster adoption without involving the Python core
developers.

For one thing, the web site has no screen shots, which is always
the very first thing that I look at when evaluating any kind of UI
based tool. I've heard the counter-argument "But people already
know what Gtk looks like", and it doesn't wash. A UI framework
which is built on top of a platform-specific widget set can have
a major influence on the final appearance of UIs created with it,
particularly when we consider automated layout.

My point is, that seeing a screenshot gives me an aesthetic
and emotional experience that cannot be described in words.
The choice of which UI tool to use is not just a technical one.
(In fact, all technical decisions are at least partly emotional --
that is, we have gut feelings about a particular technique based
on past experiences with similar methods.)

Think about this from the point of view of a programmer who
is selecting the UI framework for their next project. We start
with a list of all of the various toolkits out there. We certainly
aren't going to spend the time to download, install, and learn
the basics of every one of them just so we can decide what's
best. What we'll do instead is narrow the list down to just a few
candidates, using the information available on each package's
web site.

Unfortunately PyGUI doesn't even make it through this first cut,
because the website has so little information.

I would like to propose a challenge to the PyGUI developers:
Select an already-existing UI application, one that is fairly
complex. I would suggest PyDev as an example. Use PyGUI
to create a mockup of this application. It doesn't have to be
a fully functional app, but the widgets should all work, including
menus and basic dialogs (such as the font dialog, file open dialog,
etc.)

Then post the screenshots of that application on the PyGUI web site,
as well as make the mockup program available for download.

At the same time, the web site should be reorganized. For example,
the change list should not be on the front page. The project should
probably have its own dedicated mailing list, or at least a wiki.

Once that is done, you will have (IMHO) the bare minimum needed
to survive that "first cut" evaluation.

-- Talin