Galde support [was: Re: Accessing labels of GTree.tree_item]

Benjamin Monate Benjamin.Monate at lri.fr
Tue May 15 15:37:30 CEST 2001


On Tue, 15 May 2001 14:55:42 +0200
Sven LUTHER <luther at dpt-info.u-strasbg.fr> wrote:

> i started looking into something like that a long time ago (in late 98 i
> think), but hadn't time for it then. Also at that time, glade would
simply
> overwrite the already written callbacks, which is not fine. What is the
> current situation on it ?

Glade tries to merge the code for callbacks. When callback change name the
code is lost.
This is the same semantic in my "mlglade".

> 
> Also it could be done much nicer in ocaml than what happens in C. You
could
> simply define the new interface as a functor from the set of callback
> functions to the interface, and let the user the responsability to fill
in
> this 'callback' module and apply it to the functor. What do you think
about
> this ?

This could be interesting. You could also use a function that would take a
class of callbacks as argument. 
If you generate only virtual method you get the same semantic as for the
functor. Orelse you can provide default values if you provide a class from
which a developper can inherit (this has some drawbacks).

But : is this really useful ? 
This would increase the complexity of the generated code. Right now you
just replace the body of the callbacks by whatever you want and you have a
running application. No special understanding of Gtk is needed, and very
elementary Ocaml code is enough to write an application.

On the other side, you may apply the functor many times with different
callbacks (using the "let module" construct). This could be useful.

Could you argue about the drawbacks and good points of the functor/class
approach ?

Cheers,
-- 
| Benjamin Monate         | mailto:Benjamin.Monate at lri.fr |
| LRI - Bât. 490          | http://www.lri.fr/~monate/    |
| Université de Paris-Sud | phoneto: +33 1 69 15 42 32    |
| F-91405 ORSAY Cedex     | faxto: +33 1 69 15 65 86      |





More information about the Lablgtk-list mailing list