[rgui-dev] RE: Backend Debouch

[Curt Hibbs]

I send this off to Laurent because he did some of the initial GUI research
for FreeRIDE, and I wanted to get his comments. I am posting his reply
below.

Curt

PS
   I share Laurent's feelings about SWT.

-----Original Message-----
From: Laurent Julliard [mailto:address@hidden
Sent: Saturday, August 24, 2002 2:26 PM
To: Curt Hibbs
Subject: Re: FW: Backend Debouch


Curt Hibbs wrote:
> Laurent, do you have any opinion on this based on your previous GUI
> research?
>

Yes I do! See my comments below. Feel free to forward to the gutopia-dev
ML if you think it's appropriate.

> Curt
>
> -----Original Message-----
> From: address@hidden
> [mailto:address@hidden Behalf Of Tom
> Sawyer
> Sent: Friday, August 23, 2002 1:05 AM
> To: address@hidden
> Subject: [rgui-dev] Backend Debouch
>
>
> along with API Time, is also time to march out the backend debate.
>
> this is a tuff one. i have gone around in circles with myself trying to
> figure it out.
>
> here's the scoop as i see it. currently there are only two stable GUI
> backends in existence for ruby use: Gtk/Ruby (Gtk+) and FXRuby (FOX). (i
> discredit QT b/c of licensing issues)
>
> then there are the ones we have in the works: Ruby-Wise, wxRuby
> (wxWindows), and ParaGUI/Ruby (ParaGUI). but none of these are ready:
>
> Ruby-Wise is still alpha, although the examples i've run work well, with
> only a few bugs, it is still lacking many of even the basic features we
> would need. It would be nice if this were further along, as a clean pure
> ruby GUI would make a great start for GUtopIa. But how long would it
> take to get it up to speed?
>

While Ruby-Wise may well be an interesting project, its goal is to
develop yet another widget set from scratch. Not only developping a
widget set is a BIIIG effort (assuming you want it state of the art) but
   you also need a large audience to make it viable. And although the
Ruby community is growing, developing a widget set for the sole Ruby
community will never allo Ruby-Wise to reach the critical mass.

> wxRuby on the other hand is in the wrapper development stage, and i
> haven't heard any word on its progress, so at this point i can only
> assume there is little. (although, i know many people are hoping for
> this library asap). also i gave the python bindings a whirl and found me
> some segmentation faults. :-( i don't know where the problem lies, but
> that's not too good of a sign. yet, i am sure those could see quick
> fixes. but just the same without wxRuby itself, we ain't going
> anywheres.
>

Once wxRuby is ready that would be a good choice. However when wxRuby is
ready one can (rightly) argue that we have solved the GUItopia problem.
A unique Ruby API to develop GUI on many platforms which is exactly the
reason wxWindows was developped in the first place.

 From a design and architecture stand point, using FOX as a backend
appeals the exact same comment. FOX *is* cross-platform on Linux and
WIndows and there are persistent rumors that a Mac port could come. So
again one could argue that given the fact we have the remarkable FXRuby
interface to FOX, the GUItopia problem is already solved.

> finally, there's ParaGUI/Ruby. The bindings for this are flying along
> and looking good. That's a very good sign. ParaGUI itself though is
> still a bit of a youngster. Leon has it working fairly well, but my test
> caused my system to slow to a crawl. obviosuly there are some bugs in
> ParaGUI itself that need working out. Currently the version is 1.0.2. so
> i don't expect it to be up to par until, say, 1.2, which could take some
> time to reach.
>

ParaGUI belongs to the same family as FOX and wxWindows. I wonder why
these people didn't use one of them instead of starting yet another
project... Oh well, they probably have fun! But it will take time and
effort before it reaches FOX or wxWIndows maturity. Let alone the Ruby
interface.

> so that looks to be the lay of land. please express your opinions on
> what i've said here. what kind of time frames do you expect on these
> developing GUIs?
>
> so, we have to make some choices. should we use a GTK or FOX or both
> backends now in order to get GUtopIa "out the door" sometime soon? or
> should we patiant and wait for the others to develop? then there is the
> general question of which to support. All of them? or should we focus on
> just one? or just a few?
>

I do not participate to the discussion on the gutopia-dev ML (want to
remain focused on FreeRIDE) but 6 months after the intense discussion
that took place on the Rouge mailing list my opinion has not changed at all.

I still believe that the right approach for Gutopia is to be a Ruby
clone of the Eclipse SWT Widget Library. These guys have done a
remarkable work from a design, architecture and engineering standpoint
and they got it right.

One of the big advantage of the SWT approach compared to the FOX,
wxWindows, ParaGUI... approach is that SWT uses the native widget set of
the platform it runs on which immediately gives to the application the
native look and feel of the platform it runs on. This is to me a killer
advantage.

For those on gutopia that haven't yet looked into making Gutopia a Ruby
clone of SWT I do encourage them to consider this approach. SWT
currently support the following backends: gtk, Qt, MSWin32, Photon (QNX
Gui) and Java AWT. It offers a unified API for all these.

Some say that SWT is the what Java AWT meant to be but done right. IMHO
this is absolutely true!

Hope I haven't been too harsh in this message. At least people know what
I believe in now ;-)

Clone Eclipse SWT guys! Clone it! Go, go...

Laurent


> _______________________________________________
> Gutopia-dev mailing list
> address@hidden
> http://mail.freesoftware.fsf.org/mailman/listinfo/gutopia-dev
>