Re: [rgui-dev] RE: Backend Debouch

[Tom Sawyer]

NOTICE TO ALL GUTOPIANS: THIS IS AN IMPORTANT THREAD, SOME ADDITIONAL
INPUT WOULD BE VERY USEFUL. PLEASE EXPRESS YOUR OPINION AS THIS COULD
FUNDEMENTALLY CHANGE HOW WE PROCEED.

On Tue, 2002-08-27 at 07:29, Laurent Julliard wrote:
> Sorry for the misunderstanding. What I meant in my previous message was 
> just to create a use-once-and-throw-away tool to convert the C code that 
> makes the between the native toolkit and JNI in a C code that makes the 
> glue between the same toolkit and Ruby internals. It's just a good 
> example of how lazy I'm.... The C SWT code is extremelly repetitive and 
> for 95% of it I'm sure we can automate the translationt to C-Ruby code 
> that could then be fine tuned by hand.
> 
> I don't want any JNI interface in this, just want to avoid retyping 
> several 10000 lines of C code if we can. Am I clearer?

okay that makes more sense. so what we're getting at here is simply a
matter of using SWT C source versus using Ruby-Gnome, SWin/VRuby, and
RubyCocoa/RubyAEOSA. SWT gives us a couple of others too: Motif and
Photon, but we'd have to figure out how to address ParaGUI and possibly
Wise if Kero gets it multi-platform capable.

> That's a tough question. This requires a bit of investigation.
> 
> The SWT glue to the native toolkits as I said is extremelly basic and 
> doesn't do any fancy thing or goodies in it. This is one of the 
> *funding* principle of the SWT approach (look at the 2 articles I 
> pointed to in one of my previous message). The reason for that is that 
> they want the minimum things  and bugs to occur in the C glue and write 
> all the rest in Java (Ruby in our case).
> 
> They also make a number of assumption on how objects are garbage collected.
> 
> So I'm not sure these 2 points would fit well with the current Ruby 
> interface to the various toolkit. I'm pretty sure each of these toolkits 
> introduce goodies and Ruby'ism in the way they interface with the 
> underlying toolkit and we don't need this for a Ruby SWT

we may not need the rubyisms at that level but they certainly arn't a
bad thing to have, but i'm not so concerned with the exact underlying
API as i am about getting support from elsewhere in the ruby community.
currently i am the only one doing any coding on GUtopIa, it comes to a
relief to me that i may very well get others to maintain the particular
GUtopIa backends. with SWT it may very well end up ALL my
responsibility. (and i have a number of other projects to do as well)
 
> Once you have paved the way with say GTK and MSwin backend other people 
> can contribute other backands when they see Gutopia is good. But for the 
> time being I think this is of secondaray importance (sorry for being 
> crude here, no harm intended).

no harm done, i agree to the priorities here. but i certainly won't
abandon Kero and Leon. their work has to fit in somehow. in fact, as it
stands they are the only other persons who have made any indication of
doing coding work in relation to GUtopIa. and that's no small potato!
 
> Both. I would argue that:
> a) you will have to implement something like the java part because this 
> is how things interface with the API of almost all the underlying toolkit
> b) the second form is a higher level widget that understand text marking.
> 
> Again, SWT is full of examples like this. They have a set of widgets 
> which are bacsically a common denominator to all underlying toolkit and 
> then on top of it they have higher level objects.
> 
> if you think about this is only when you have the a) type of things 
> working and rock solid that you can build b) things in confidence and be 
> assured that the "write-once-look-the-same-everywhere" principle will apply.

i see your point: (a) would be "under-the-hood" to accomplish (b)

> I don't think my view is incompatible with yours. What I'm saying is 
> that SWT is a great source of inspiration on how to *do* (=implement) 
> things from an engineering standpoint. If you have it right like the SWT 
> people did then you can confortably build any level of sophistication in 
> pure Ruby either in terms of widgets or programming model.

hmmm...so back to the main point: SWT C source versus using Ruby-Gnome,
SWin/VRuby, and RubyCocoa/RubyAEOSA. okay, here are, point by point, the
questions i need answered:

* who will do the "JNI" C translation for Ruby. i fear it is out of my
league, as i haven't used C for over 10 years.

* if we use SWT who will build the respective GUtopIa backend
interfaces? I can hadle one of them (GTK's) while i hammer out the the
primary meta-api, like i'm doing presently, but not all.

* how do we integrate ParaGUI, Wise, or other backends if we use SWT?

* finally, is licensing an issue?

~tom

p.s. i read most of those readings you linked for me and also looked at
the java code a bit. they make some fair arguments and i have already
implemented some of those notions into gutopia. the java code is quite
large, just a single widget had what appeared to be some odd thousnad
lines of code. is this perhaps due to the one-to-one correlations? well,
there was a lot of remarked docs in there too, so i'm sure that counts
for a good bit. it just seems rather large to me, but perhaps that's
just how it ends up when complete and i'm being nieve.