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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
