From: Christian Boos Date: 2002-01-22T20:21:39+09:00 Subject: RE: RANT: Ruby GUI API This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C1A33F.53CA2B70 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit On the topic of GUIs for Ruby ... [Warning: this is a long mail, which, among other things, talks about licensing issues... It is by no mean an attempt to start a flamewar. ] I can give some feedback from my personal experience. I'm coming from the C/C++ world, but had mostly experienced in GUI programming with Tcl/Tk. I liked the 'wish' shell which enables you to interactively test several alternatives. I also enjoyed the richness of Tk, its design, the powerful canvas and text widgets. In 97-98, I heard about Qt, and discovered that with a well thought library, C++ is indeed usable, even pleasant to use. Since 2000, we use Qt in the company I work for, in a cross-platform environment, and its adoption has been nothing but a huge success for us. In the past 6 months, I've been in the process of discovering Ruby, and, quite naturally, I became interested in Ruby/Qt2, from Nobuyuki Horie (see the RAA for more). I must say that he has done a very high quality job, the interface to Qt2 is very complete, and there are only a few limitations (*). Even the Qt Designer is supported: there is a 'rbuic' tool that generates Ruby code for the corresponding interface described in .ui files. For me, it was really like 'wish' meets Qt! IMHO, Qt is the ideal candidate for being the "standard" graphical user interface for Ruby. Let me give some arguments in favor of that position. Qt's strengths (in the context of its use from Ruby): ------------------------------------------------------ * Really cross-platform: nearly all flavors of UNIX, all flavors of Windows, embbedded platforms, and the Mac (but for the later, that's speaking for Qt3 only). I don't know about any other toolkit that has the same "production" quality on all their supported platforms. * Native toolkit: no other intermediate layer (as opposed to, say, Tcl/Tk). The access to the "hardware" is as direct as possible (GDI on Windows, all possible extensions (incl. XRENDER) on X Window, direct access to the framebuffer on the embedded platform, I don't know for the Mac). * Well-thought API: as said before, the ease of programming Qt makes even C++ a friendly language, to the point that if there would exist a C++ interpreter, I would maybe never have discovered Ruby! Qt (which dates back to 93) is really a precursor of the POLS :) * Powerful features/extensions: it is possible to use Qt together with legacy applications and as a Netscape plugin; it interfaces nicely with OpenGL applications; has a very powerful drawing/image manipulation model (the painting code is one, the 'paint device' can be a widget, a pixmap, a printer, a graphics metafile, a SVG file (Qt3)); it has XML support (SAX and DOM APIs); it has a DBI-like layer (Qt3); I'm sure I forgot something :) * Support: one of the most controversial position that Matthias Ettrich (KDE's project founder) defended was about support: as Qt was a commercial product, he thought it would be well supported and would allow him to concentrate on what he wanted to do, a Desktop. However, it was not blind reliance on some random closed-source product: the fact that the code was available (even in Read-Only mode) made that choice possible (not "safe", but the benefits outweighted the risks). Five years later, this strategy proved to be successful, to both sides: KDE is an admirable achievement and still an ongoing success story, Qt is now GPL'ed, Trolltech is a successful company, etc. Five years later, his point is even more valid: Qt is very mature, is actively supported, the new Qt3 has a lot of new features, it is available on all platforms, it is bundled with most (if not all) the Linux distributions, and is even available without cost for Windows in the non-commercial edition. Qt's limitations: ----------------- Well, its availability on Windows, as said before, is without cost only for the non-commercial edition. The professional or enterprise edition (same code, but different use) has to be bought from Trolltech, whenever you write a commercial application OR you work in a commercial setting (i.e. you use it at work). For accurate details, see http://www.trolltech.com/developer/licensing/noncomm.html and http://www.trolltech.com/developer/licensing/noncomm-notes.html Also, the NC edition is available for qt-2.3.0 only (a very stable release, though). Of course, those facts are disadvantages from the point of view of "free software" under Windows. If you happen to think that when you are paid to write software on a non-free plaftorm for commercial purposes, it is reasonable to expect that you could also pay for some of the tools you are using, (as you usually do for the compiler), this is a non-issue. If you are really intransigeant about using free software only, well, remember we are talking about the Windows platform :) Ruby/Qt: -------- For me, Ruby and Qt are both two outstanding pieces of software. Their combination is very powerful. (*) That said, there is still room for improvement on the way the binding is made. As I'm still half as competent as Nobuyuki on that matter, I shouldn't complain too much :) My wish is that a latter version of Ruby/Qt could do the wrapping the same way PyQt did, using derived C++ classes that know about Ruby (so that overriding virtual C++ methods by Ruby methods would be possible), that blocks could be used as slots, and, last but not least, a support for Qt3 ! Thanks for reading, -- Christian Boos -- Consulting Software Engineer -- BCT Technology AG > -----Original Message----- > From: Sean Russell [mailto:ser@germane-software.com] > Sent: Monday, January 21, 2002 6:16 PM > To: ruby-talk ML; undisclosed-recipients: ; > Subject: RANT: Ruby GUI API > > > I started this rant in another thread, where it was way OT, so I'm moving > it here. > > As I said in another thread, to-native compilation and a Standard > Ruby GUI > API that isn't Tk are the major limiting aspects of Ruby as used as major > application development environment. This isn't to say that you > can't use ... > -- > --- SER > > ------=_NextPart_000_0025_01C1A33F.53CA2B70 Content-Type: text/x-vcard; name="Christian Boos.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Christian Boos.vcf" BEGIN:VCARD VERSION:2.1 N:Boos;Christian;;Dr FN:Christian Boos NICKNAME:cb ORG:BCT Technology AG;Development TITLE:Consulting Software Engineer TEL;WORK;VOICE:+49(0)7852996206 TEL;WORK;FAX:+49(0)7852996100 ADR;WORK:;;Im Lossenfeld 9;Willst=E4tt;;D-77731 LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Im Lossenfeld = 9=3D0D=3D0AWillst=3DE4tt D-77731 URL: URL:http://www.bct-technology.com EMAIL;PREF;INTERNET:cboos@bct-technology.com REV:20011205T163634Z END:VCARD ------=_NextPart_000_0025_01C1A33F.53CA2B70--