-----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-----