Re: [rgui-dev] RE: Backend Debouch

[Laurent Julliard]

Tom Sawyer wrote:
> Laurent,
>
> that had occured to me. personally i have no idea what a JNI for Ruby
> API would entail. but despite that there are still some things to
> consider:
>
> creating some sort of C-JNI to C-Ruby translator would lock us into Sun.
> i don't know that exact licensing of JNI technology, perhaps you do, but
> my hunch is that its not pure open source. also we would then have to
> subsequently keep up with the changes to JNI, as well as SWT. (i assume
> SWT is open source) but perhaps you are suggesting that we not actually
> tie in with JNI, but simply steal the SWT C code and convert the JNI
> parts of the Java code into equivelant Ruby code? like i said i don't
> know too much about doing something like that. i also wonder if we would
> then be left to support our own fork of the SWT C code? do we want to do
> that? these questions i am unclear about. but there was some interesting
> talk about doing the same sort of thing with EJB the last few days on
> ruby-talk. the general opinion was that the Ruby community should do
> their own rendition, borrowing from EJB, but not actually harnessing any
> of that code straight out. food for thought.

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?

> more importantly, by using the C SWT code instead of the current
> existing Ruby bindings to the various platforms, i.e. Ruby-Gnome,
> SWin/VRuby, and RubyCocoa/RubyAEOSA, we are abondoning valuable Ruby
> developers that could be of great help to our project. The C SWT code
> may be very good, i will grant you that, but is it worth loosing the
> support of great ruby coders like of Masao Mutoh, FUJIMOTO Hisakuni, and
> a number of others? if they see just how good GUtopIa is, and knowing
> that their toolkits are being used for it, i am certain that they will
> be very ready to lend a hand and even become the maintainers of their
> respective backends. if i am not mistaken, Leon and Kero are already set
> to do this for there particular API's. which brings me to my next
> thought.

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

> C SWT in no way helps us with bindings to Ruby-Wise or ParaGUI. you may
> think these unimportant and i won't argue that getting a good
> multi-platform gui for ruby asap isn't more import then supporting
> eiterh of these particular backends. certainly it is. but if we can do
> so such that we still have these potential backends as well, wouldn't
> that be even better?

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

> finally, and my largest concern, by doing what you suggest, i am worried
> that we'd be locking ourselves into doing things the SWT way, rather
> then the Ruby Way or the GUtopIa Way, and thus would have limited
> freedom to do things BETTER. take for instance the idea of Component
> Textual Markup which i am planning for GUtopIa. with it one can add text
> to a Text widget with various styles much more easily than you can using
> SWT. For example this code in SWT:
>
>         widget.setText("This is the StyledText widget.");
>         // create the Colors
>         Color orange = new Color(display, 255, 127, 0);
>         Color lime = new Color(display, 127, 255, 127);
>
>         // make "This" bold and orange
>         StyleRange styleRange = new StyleRange();
>         styleRange.start = 0
>         styleRange.length = 4;
>         styleRange.fontStyle = SWT.BOLD;
>         styleRange.foreground = orange;
>         widget.setStyleRange(styleRange);
>
>         // make "StyledText" bold and lime
>         styleRange = new StyleRange();
>         styleRange.start = 12;
>         styleRange.length = 10;
>         styleRange.fontStyle = SWT.BOLD;
>         styleRange.foreground = lime;
>         widget.setStyleRange(styleRange);
>
> translates into something like this in GUtopIa:
>
>   widget.text = "<#FF7F00><b>This</b></#FF7F00> is the " \
>                 "<#7FFF7F><b>StyledText</b></#7FFF7F> widget."
>
> which do you prefer?

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.

> please consider all this carefully. i can tell you are very psyched
> about the idea of having a "SWT for Ruby" and that certainly has merit.
> perhaps too, you believe by lifting the SWT code we can get this done
> faster. i can understand both these thoughts. but be reassured, while
> our work may not be as refined as SWT for awhile, we will actually have
> a basic working system of extrodinary capability beyond that of SWT in
> rather short order.

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.

Laurent

--
Laurent JULLIARD - Xerox R&T/SSTC/XPA - Open Source team
>> Host your Xerox Software project on CodeX: http://codex.xerox.com
>> address@hidden community: http://xww.linux.world.xerox.com