((comp.lang.misc + cc: ruby-talk ML)) Dave Thomas <Dave / Thomases.com> wrote > Yukihiro Matsumoto <matz / netlab.co.jp> writes: > > > And I think the market, not me, will decide which GUI toolkit should > > be the default, iff there can be the *market* of free software. > > > > Anyway, I really want to see Ruby/wxWindows working. A new > > library/toolkit is always welcome. > > I'm slightly concerned about this. I think it is great that we give > developers a wide choice of GUI toolkits. However, from the user's > perspective, it means that they could have three Ruby applications > that require that they download and install three separate (and large) > packages before those applications run. This is a very important point. If we really want Ruby use to take off, we really need to consider the perspective of more ordinary users and managers, rather in terms of the way that hard core programmers that can do whatever they please with their systems think. There is much less incentive to develop with any particular GUI toolkit because of the difficulty of getting sufficient critical mass, and many people gravitate to platform-specific GUI interfaces out of convenience, greatly reducing the overall synergy. The only generally successfully way to overcome this in the past has been bundling in the distribution: Tk with Tcl, AWT (recently Swing) with Java, and Tkinter with Python. A default GUI interface as part of the Python standard distribution is one of the things besides maintainability that reportedly makes Python more attractive than Perl to managers. (If you don't think that what managers thinks is important with respect to the spread of new technology, ask yourself why Dilbert is wildly popular among programmers, among other groups. Not to mention that such concerns are often well founded, given learning curves and turnover and so on.) > So... do you supposed it would be possible to define a common GUI > interface for simple Ruby programs, one that would map onto Gtk, > Tcl/tk, and wx. It would obviously be a lowest-common denominator > interface, but for many simple applications, that would be > enough. This would then give the user the ability to choose, even at > run time, which particular toolkit to use. ... > This would be a kind of DBD/DBI for GUIs. > > Is this too ambitious? I know that groups of Perl people have repeatedly contemplated this and have repeatedly given up on it because of a host of troublesome technical details and the apparently excessive amount of resources required to produce what might be a fairly mediocre result. I don't recall the details, however. I would be extremely wary of trying to do something that the vast pool of talent in the Perl world has repeatedly backed away from. I think the Pythons have run into the same sorts of practical problems that the Perl people did, and most of their discussions that I've sampled seem to turn back instead to the issue of what would be the best _existing_ choice for their next default GUI. Anyway, having a default GUI is something like having a default implementation of printf from a utility point of view. There are a great many applications that could be implemented with just the standard Ruby distribution if it contained a ready-to-use GUI interface. This would make it much easier to promote Ruby projects and get many Java and _Visual_ Basic people to try Ruby. It would make Ruby an ideal teaching language at all educational levels. Despite the huge number of Perl modules, Perl catches on in most shops as a tool that is built, installed, and used out of the box "as is". The same Perl program that works on one machine with a standard install will work on others with a standard install. This is not true once you start requiring custom modules, and this is why Perl wizards may do Perl GUIs from time to time, but normal Perl users almost never do. GUIs are now important enough and generally useful enough that it would give Ruby a big advantage over Perl (and make user's lives much better) if all Ruby distributions/installations included a default GUI. The important thing to remember is that maybe 90-95+% of all Perl users in the world are pretty much restricted to whatever is in the standard distribution. This will be true for Ruby as it spreads world wide and catches on. Others who produce tools for such people have to pretty much follow suit in sticking to what is in the standard distribution if they don't want to exclude the great majority of users (which is not a good way to promote new tools in most companies). Conrad ====================== Other posts have raised other questions regarding wxWindows. Rather than trying to respond to each individually, I've copied what I hope will be interesting and useful information here. The first thing I would recommend is actually looking at the discussions of why it currently appears to be more or less the most favored choice among Python proponents. After all, the Pythons are generally concerned with the same sorts of issues we are. For those of you who don't want to scan the endless GUI posts in comp.lang.python, I've quoted some text from the previously cited URLs. Comparison of Python GUI interfaces, distilled from newsgroup discussions: http://www.nl.linux.org/~gerrit/gui.html WxPython After Tkinter, this is the most common GUI. It's a binding to wxWindows. WxWindows itself is written in C++, so it's beautifully compatible with Python's object-oriented nature. It's very easy to translate C++ calls to Python calls. Eric S. Raymond asks: Why the hell hasn't wxPython become the standard GUI for Python yet?. The answer to this question is: Because Tkinter is more portable. WxPython is relative very fast: see this benchmark by Gordon Williams. WxPython is very active developed: both wxPython's creater Robin Dunn and the wxWindows people are adding a lot of features. There are stable and unstable releases. The wxPython community is very kind. A strong point of wxPython is the builtin printing support (for Tkinter, you'll need to download extra libraries). wxWindows home page: http://206.101.232.131/ What wxWindows is and is not wxWindows is a set of libraries that allows C++ applications to compile and run on several different types of computer, with minimal source code changes. There is one library per supported GUI (such as Windows, GTK+, Motif, and Mac). As well as providing a common API (Application Programming Interface) for GUI functionality, it provides functionality for accessing some commonly-used operating system facilities, from copying and deleting files to socket and thread support. wxWindows is a 'framework' in the sense that it provides a lot of built-in functionality, which the application can use or replace as required, thus saving a great deal of coding effort. Basic data structures such as strings, arrays, linked lists and hash tables are also supported. See wxWindows 2 Classes for a list of the available classes (a little out of date now, so please also see the online class reference). wxWindows is not a translator from one GUI from another; it cannot take a Motif application and generate a Windows application, for example. You need to learn a new API. However, the wxWindows API has been praised for its intuitiveness and simplicity, and can be far easier to learn and use than a native GUI API such as Motif or Windows. Porting from MFC is particularly easy due to its similarity: one user has ported his CASE tool from MFC to wxWindows in a couple of weeks. Such a toolkit is not unique - there are others to choose from - but wxWindows is free, well-established, well-documented, and very broad in its coverage of GUI functionality. It has some extras that make it stand out from the crowd, such as the many convenience dialogs, built-in HTML display and printing, virtual filesystems, easy-to-use OLE automation controller class, Open GL support, and many other features that make it easier to write modern and user-friendly applications. .... Where now? The weight thrown behind GNOME and GTK, by Red Hat Labs and others, could thrust wxWindows into a fairly important position, as the only tool that can be used to produce GNOME-compatible products as well as Windows, Motif, Mac and maybe other versions. Linux is becoming an increasingly important and respected variant of Unix and this will result in some mainstream wxGTK applications. The Motif port will remain important for commercial users, and of course Windows isn't about to disappear in a hurry. Indeed, the Windows port could be adapted to Windows CE, with palmtop sales increasing all the time. Programmers may be beginning to question the value of MFC, with rumours of decreased development of the product by Microsoft; and wxWindows 2 may be a beneficiary of a renewed lack of faith in the Microsoft juggernaut, and disgust with their business methods. Similarly, the computer press is reporting an upsurge of scepticism in the abilities of Java to cater for the needs of real-world cross-platform projects. Developers are looking at the alternatives.