[ruby-talk:01668] Re: New Ruby projects

((comp.lang.misc + cc: ruby-talk ML))

Dave Thomas <[e-mail]> wrote
> Yukihiro Matsumoto <[e-mail]> 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.