gutopia-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [rgui-dev] RE: Backend Debouch


From: Curt Hibbs
Subject: RE: [rgui-dev] RE: Backend Debouch
Date: Wed, 28 Aug 2002 07:26:35 -0700

Tom Sawyer wrote:
>
> lets' not jump too fast. you guys are very excited about this, but lets
> follow through with the inspection before flying the plane. :-)

Ok

> now, as i said earlier we should consider carefully the work of some of
> the other's in the ruby community with regards to the work they have
> done on thier respective bindings:
>
>       MASAO Mutoh, Ruby-Gnome
>
>       NISHIKAWA Yasuhiro, SWin/VRuby
>
>         FUJIMOTO Hisakuni, RubyCocoa
>
> now these men have wroked independently to produce thier respective
> bindings, whith much thought and care. while i know this is rather
> subjective: how do you think this work then compares to SWT? in other
> words, who are the persons responsible for SWT? it is important to
> realize that it is not likely that we will gain any significant support
> from whoever these JAVA developers are.

This would be a new deveolopment. Essentially, we would be stealing the
design and architecture. While the wxisting SWT is cross-platform, it is
Java-specific and cannote be reused by us (in the same way that a Java
programmer couldn't make use of Ruby-Wise).

We can, however, port the C based portion, which is purposefully designed to
be the absolute minimum amount of C code needed to provide uniform access to
the underlying platform widgets (windows, mac, gtk) from Ruby code (or in
their case, Java code).

This is the same role the SWin plays in SWin/VRuby, except that it is only
for windows.

> now, just as important, i must ask, have any of you actually used SWT?
> and i mean beyond that of a simple demo? i read this page:
> http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-h
> ome/dev.html
> and it seems that the Linux-Gnome part is only for GTK2 and has
> performance issues. the MacOS part dosen't work yet at all. Only the
> Windows and Motif support appears reasonable. So we arn't quite as
> multi-platform with SWT as we'd like to be. yes, this will improve. but
> for now we are simply dependent on what the SWT team has to give us if.
> i also see that SWT is designed first for one-to-one binding to Windows,
> only after that are the other interfaces worked out. that kind of bugs
> me, although they keep it at such a low-level that it dosn't amke a
> large difference.

I've used Eclipse, which (as you've probably read in the document above),
runs well on Windows.

We wouldn't be dependent on the SWT team at all -- because we can't really
use their code (as I said, this would really be a new development, from
scratch). Unfortunately, this also the downside, because it would be a
really large effort.

> finally, let us consider what the endeavor of SWT for Ruby really
> involves. first were talking about stealing the SWT C Source. Hell, with
> Ruby/DL does this need any modification at all? it would be best if it
> did not. so, Curt what is there to do there? then we have to write
> Ruby/DL code to bind to the C code. essentially we're building a wrapper
> using Ruby/DL rather then say SWIG. this is where the work lies! in
> doing so we are largly translating the SWT Java code, since the Java
> code does little more then pass straight thru to the C. i've looked at
> the Java code some, and personally, unless someone can make some sort of
> automated way to convert that code to Ruby/DL it will take a very long
> time to create the equivalent in Ruby. those are my thoughts on this, i
> am not quite clear on what needs to be done to pursue this. Curt? could
> you think this through and come up with a possible detailed game plan?
> so we can wiegh the SWT option with respect to what it actually
> involves?

Now you've got me :-)

While I personally believe that the SWT approach is really the correct one
for the long term, it really is a very large effort and would require a
significant team of Ruby developers (or at least three of you, Tom :-).

A more practical solution is back where you started -- a wxWindows binding
to Ruby -- because wxWindows does provide all of the essential features, and
 is a mature GUI library. In retrospect, I think it would make more sense if
I contact Bob Calco and see where he is with the wxWindows binding and
either join forces with him, or take it over.

What do you think?

Curt





reply via email to

[Prev in Thread] Current Thread [Next in Thread]