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

Re: Greetings!



On Thu, Jun 08, 2000 at 04:15:40PM +0000, Georges Mariano wrote:
> Sven LUTHER wrote:
> 
> > 
> > That said, Georges mariano is directing a TER about the difference between the
> > different ocaml GUI possibilities, how did this work out Georges ?
> Well, I was puzzled by the fact that there is two possibilities to
> interface ocaml code with Tk (namely labltk and ocamltk)
> [same question for gtk...
> Sven is right, it's is always preferable to keep the choice alive ...]
> 
> We begin to use lablgtk, and it is easy to use (if you have (a little)
> experience with Tk "philosophy", and it is my case...:-)
> Labltk is also a very good example for an effective use of labels
> and optional arguments (Ocaml3.00). I think this is the only way
> to have a very nice GUI code... First tests were very successful ;-)
> 
> BUT... I think that in the middle term, it would be preferable
> to improve ocaml/gtk bindings... To speak briefly, 
> camltk is looking to the past, labl*GTK* (or mlgtk) is looking to the futur...
> (of course, gtk programming is more complex... :-(
> 
> Conclusion : It is judicious to encapsulate GUI specific code in
> 	specific modules and to write ocaml code in a way that
> 	delay the choice of the final GUI library...
> 	Yes I know, it's easy to say.......................

What would be nice, is to take some examples of gui for varous needs, and
implement them in all 5 of ocaml gui stuffs (maybe adding the native toolkit
used in efun if i am not wrong). with comments and other such stuff.

> > Also as notice, i have been developping a c2caml tool to produce automatic
> > ocaml bindings for C library from the .h headers, that i wanted to use to
> > automatically generate such bin=dings for forthcomming gtk+ versions, but have
> > no time to work on it :(((. It already parses gtk/glib headers correctly,
> > though.
> Can you describe the remainig work ? Which part is effectively working ??
> What kind of effort would be necessary to reach the end of this task ??

Well, it parses the stuff and put the information (almost all of it,
enumeration are still a bit problematic) into a nice listy ocaml structure.
Maybe a bit heavy and hacky, but i did it quickly one sunday afternoon. Now i
have some idea's of how to translate each C construct into the corresponding
bindings, both from the mlgtk experience, and from the work of my TER student.
(she did make a word document, but it is not very complete and in french.)

You can have a look at it at : 

http://dpt-info.u-strasbg.fr/~luther/perso/c2caml/c2caml.tgz

or from the web page at : http://dpt-info.u-strasbg.fr/~luther/perso/c2caml

then there are thoughts about how to separate/group various .h files in
different files, and generate documentation and other such stuff.

What would be nice is to but the translation tactics into some configuration
files, and then have a way to assign tactics to different function/type names
of the .h

Also in the current code, i preprocess the files, so they become quite big, so
it is needed to separate parsing for getting information from the .h and those
that are in the file being generated, and other dependencies.

C2Caml is under GPL, and if more people are interrested in it, i could put it
at sourceforge or some other such place, and we could start a group work on
it.

Friendly,

Svne LUTHER



Reply to: