Re: [rgui-dev] Idea for binding to the low level api

[Tom Sawyer]

i've been thinking about the binding issue as well. specifically i've
been thinking about the notions of translating one api into another. is
it possible to define one to one translations, or near one-to-one? isn't
that what SWT kind of does?

for a moment imagine ditching the idea of a meta api. and instead we
create transalation tables:

'FXWindow(FXComposite* p, FXuint opts=0, FXint x=0, FXint y=0, FXint
w=0, FXint h=0);' => 'GtkWidget* gtk_window_new (GtkWindowType type);'

the difficulty is of course that things arn't one-to-one. as with the
above example, the prameters don't match up. we have to get a little
more expressive..... actually i have to stop here. i was goign to try to
take in further, with the idea that if we could write such tables then
we could just translate an app written for one gui into any other and
vice-versa.  but this demonstrates just how quickly doing so becomes
impossible. trying to match up the api code for a Fox Window and a Gtk
Window just dosen't fly. Because the very foundations of the two differ,
and although some things coorespond, far too much has no correspondance
whatsoever.

that is why one is essentially relagated to creating a meta-api that
exists on a level above all the possible apis it can translate down to, 
neccessarily leaving out certain aspects of those apis that would cause
the meta-api to be TOO HIGH.

knowing this. you have to be impressed with something like wxWindows. no
wonder its 10 years old! :-) that's how long it would take to do such a
thing thuroughly for numerous platforms.

thus, i have to return to my earliest notions about all this: DON'T
TRANSLATE. IMITATE!

personally, i have yet to see wxWindows in action. my wxPython tests had
some problem. i'm curious to see just how well it works with Ruby.

but i digress. i don't think the best approach is to do translation or
generation either. instead we should use or create our own singular
low-level toolkit upon which we can build GUI's that blend into whatever
environment they happen to be in. like a Chameleon.

to do otherwise just raises far to many difficulties and
inconsistancies. and in fact, i think it would actually be less time
consuming to write your own toolkit from scratch then try to write even
a mildy effective translator/generator.

but i will add that massimiliano's idea of separating form and function
would lend itself to the translator/generator approach, simply becasue
it wouldn't matter if, say, the windows version didn't "form" like the
gtk version, the essential functionality would be the same.

~tom

signature.asc
Description: This is a digitally signed message part