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