[ruby-talk:15204] Re: Q: GUI framework with direct drawing ca pabilities?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Je Mardo 15 Majo 2001 11:29, vi skribis:
> Would it be a good idea to develop a pure Ruby GUI framework built on top

Yes!  I've been thinking the same thing.  Something at a higher level of 
abstraction from the toolkit that actually does the widget drawing. I've put 
some thought into this, even before I discovered Ruby, but the issues are 
common to portable languages.  Caveat: I'm going to talk about stuff which 
may be common knowledge for a lot of people here.

Java tried with limited success to build at abstracted windowing toolkit with 
AWT.  AWT was a great idea, but had some serious limitations.  This is why 
almost every modern Java application uses Swing, which uses a different 
metaphor for GUI creation.

AWT is simply an abstract GUI layer which is intended to rest on top of 
native components.  When you create a Button, for example, AWT just goes to 
the underlying windowing environment and asks for a Button.  The potential 
benefits here are speed (a native toolkit draws widgets, not the slower 
interpreted or P-code) and native look-and-feel: if you run AWT on MacOS, you 
get a MacOS look-and-feel: run it on Windows, and you get a Windows 
look-and-feel.  You also tend to get some freebees in the interaction 
department, like auto clipboard support and so on.  The limitations are many, 
but most of them arise from the fact that not every OS supports the same 
widget features.  Therefore, your widget options are the subset of widgets 
that are supported by all GUIs, which is much smaller than the set of widgets 
supported by any one GUI.  It is also very difficult to control the behavior 
of native widgets from your program.  Your applications are difficult to 
develop, because in the end, you really have to test your application on 
EVERY platform to make sure that the idiosyncracies of a particular GUI don't 
screw up your application.  The end result is that AWT apps are ugly, clumsy, 
and nobody uses them.

Swing, on the other hand, relies on almost none of the native widgets for GUI 
generation.  All Swing widgets are drawn by Java code.  The result is a 
dynamic, attractive, highly extendable, highly configurable, full-featured 
toolkit.  Your applications look the same on all platforms, so you generally 
have to do minimal testing on the target platforms.  The downside is that 
Swing is slower than AWT, it is larger than AWT (both in library size and the 
memory requirements), and you don't get native look-and-feel.  People 
generally don't like to be presented with a different widget set for each of 
their applications.  To be honest, this is only a problem for OSes other than 
MacOS or Windoze;  Sun is pretty intent on keeping a Windows style 
up-to-date, and Mac appears to be investing a lot of effort in keeping the 
Aqua style in sync.  However, the only real option for Linux users is Motif 
(who uses Motif anymore?) or Metal, neither of which looks anything like any 
style available for KDE or Gnome other than the Metal L&F.  Personally, I'd 
rather my apps take on the L&F that I choose, rather than me having to choose 
a L&F that matches an app I use.  Anyway, the size and speed issues are 
probably more important.

This given, I would expect the same problem to face a potential Ruby GUI 
toolkit.  You'd want an abstract layer to be full-featured, but experience 
shows that this is incompatible with relying on native toolkits.  Ergo, you 
have to provide your own toolkit.  Which is a real effort.

We're talking about duplicating the work in FX, FLTK, or TK.  It is a matter 
of taste, but I find all of these toolkits to be, well, ugly.  FX is not as 
bad as the others, but none of them compare to QT, GTK, or even Swing.  Worst 
of all, there is no core communication between any of these and the native 
GUI, which means you can't write applets for the Kicker, the Gnome panel, or 
AfterStep.  Any support for embedding has to come from the native environment 
side.  I'm not sure that there will every be a solution to this problem; 
perhaps CORBA or XML-RPC will help, although CORBA is bloated and XML-RPC is 
relatively slow (as RPC mechanisms go).

I have yet to see an API for any of these toolkits that is as elegant or 
easy-to-use as the MUI (Magical User Interface) toolkit API from the old 
Amiga or as Swing (although Swing leaves a lot to be desired as well).  GUI 
layout design is still a pain in the rear; it always has been, and it may 
always be so.

In the end, I think that the best solution is to design GUI API for Ruby, and 
then require toolkit bindings to conform to that API.  This does make sense 
and is common practice in many other API toolkits; SQL DB access, for 
example, in almost every language is normalized, with the ability for the 
user to plug in a variety of subsystems.  The biggest problem is, of course, 
the AWT LCD issue, but I believe that some of Ruby's features would help to 
alleviate these problems.

=== SER   Deutsch|Esperanto|Francaise|Linux|Java|Aikido|Dirigibles|GPG
=== http://www.germane-software.com/~ser  jabber.com:ser  ICQ:83578737
It occurs to me, however, that there is one fundamental difference between
what /they/ want, and what /we/ want.  Both government and citizens want
pervasive computing; the difference is that citizens want to be able to turn
it /off/.                         -- SER
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7AYHZP0KxygnleI8RAncHAJwIPEKjpXsYUsjevypzQzE29F/WIwCdEmNv
vle9TZQH4sfx9oqsCPwTO+0=
=s6vp
-----END PGP SIGNATURE-----