Re: OCaml's long range graphical direction?

[Sven <luther@dpt-info.u-strasbg.fr>]

On Thu, Feb 08, 2001 at 10:59:41AM +0900, Jacques Garrigue wrote:
> 
> From: Sven LUTHER <luther@dpt-info.u-strasbg.fr>
> 
> > Also there is work underway for a framebuffer port of gtk+, this could be a
> > nice tool for embeded system running only ocaml or some variant thereof. I
> > think we will see macos X support soon, if you don't want to use X on it.
> 
> Yes, the activity around GTK+ is very encouraging.
> 
> > > Caml-GTK interface is still actively developed and hence might be less
> > > stable than the Caml-TK interface.
> > 
> > And with the forthcoming of gtk+ 2.0, there is need for a lot of work in that
> > area.
> > 
> > Maybe this is something for the new ocaml consortium ?
> 
> Not so sure: interfacing to GTK requires quite a bit of design, and
> I'm not sure how much of it can be delegated.
> Anybody knows when GTK+ 2.0 will be ready, anyway?

I think the answer is it will be ready when it is ready.

But it may arrive sometime soon.

I think also, that if we are serious about this, we need someone from the ocaml community who is active in gtk+ binding to take a more active part in the gtk+ design stuff, or at least to be in contact with them.

In particular, they claimed that gtk+ was designed to be easily interfaced to other languages, but much of the set/get functions are missing, forcing one to access the structure directly.
> 
> > That said, we still have 2 gtk+ bindings, at least.
> > It seems lablgtk is more complete and may have more active support, due maybe
> > because jacques as more time to devote to it than i and pascal cuoq do.
> > But still mlgtk seems more easy to understand and to use, needing less
> > understanding of the convoluted class and methods system that lablgtk uses.
> > Both lack good documentation, well apart from the source that is.
> 
> This convoluted class and method system is intended to make using
> lablgtk easier on the long term :-)

No doubt, but i think the main problem is that you have to read lot of source files to be able to understand how it works.

Without a full doc, just a small document explaining how the different methods are grouped in classes and method's method would be a nice plus.

(in particular, for event handler connector, there is the #event, the #connect, the #after#connect, and so on. This is particularly disorienting at first.)

> In fact, people seem to be coping with it OK. That is, I didn't get
> that many questions on it. But certainly, there is a huge deficit in
> documentation.
> 
> > It would be nice to know who is using which of the bindings and what is their
> > opinion on it ?
> 
> Yes, for sure, I'd love to here more.
> I had a bit of feedback for lablgtk: Pierce&Jim's unison (I forced
> lablgtk on them by writing a UI), an airplane route analysis tool, a
> frontend for a database, etc...
> Also somebody here developped an irc client, and a binding for
> mozilla's gecko for another project. We shall make the effort to
> release these individually.

I am more speaking in term of toolkit usage.

Let's ask the question more precicely :

Who is using lablgtk and who is still using mlgtk ?

If i am the only one using still mlgtk, maybe it is not worth it, and we could take some of the nice stuff from mlgtk and port it to lablgtk. In particular, there is the gtkEasy layer, and it was once reported that the thread handling of mlgtk is better of how it is done in lablgtk, but then i am no thread guy, so i don't know myself ?

Any comment on this, Pascal ? David ? the mlgtk thread author ?

> > Also both use an object layer over an type unsafe non object layer. It seems
> > that this seems an hindrance for some, from previous comment on this.
> 
> Not completely exact: the non-object layer is also type safe in
> lablgtk. You theoretically can program in it directly. This is just
> going to be much more verbose. Also a bit more error-prone, since not
> everything is captured by the type system.

Ok, ...

i think that this may appeal to people not wanting to use the object layer. Maybe it could also be developped and documented (more easy, since mostly it is a translation of the gtk+ C documentation).

> > Ideally it would be nice to have a stub layer that will be used by both
> > bindings, if they are not merged, and could even be used standalone or with a
> > more type safe non object wrapping, if this is possible.
> 
> Personally I would rather favor a merge of the two-bindings. I believe
> this is what most people want, and there is enough work for both
> teams.

same thougth, but then, i think the object layer of lablgtk and mlgtk are vastly different.

This is way i think it would be helpfull to know Who is still using mlgtk.

Like said, if it is only me and a few others, then it is not worth it.

> Or would it be possible to build a mlgtk compatible layer on top of
> lablgtk's non-object layer?

Err, ...

Not exactly.

There are two part of mlgtk (well 3 actually, counting the non-object stub layer).

There is the Gtk/Gdk and Glib modules, which i think are vastly incompatible to the current lablgtk things. They could be adapted to be on top of the non-object layer of lablgtk i think, but that is the extent of it.

But there is the other layer, which is more high-level than that, and which could easily be ported to lablgtk+.

It is the easy layout and menu stuff. Which makes building an interface very simple and easy.

> > Also i advocate the use of automatic or semi-automatic translation
> > of the gtk+ C headers for creating the stub layer, so as to make the
> > tracking of changes in gtk+ easier.
> 
> I'm all for it. But this is lots of work, especially if you want the
> intermediate layer to be typed.

Lot of work, but work sparing in the long end. 

> > But then again, this is work that need to be done, and i personnaly
> > don't have the time for it.
> 
> All problems come to that :-)

But let's hope that the Consortium would help here, this is after all a very important part for ocaml's acceptance.

> 
> > > > To what degree does threading affect the answer?
> > > 
> > > No idea.  I've heard plenty of claims that multithreading helps
> > > building good GUIs (see e.g. BeOS), yet most popular GUIs (including
> > > TK and I think GTK too) seem to manage fine without multithreading.  
> > 
> > Well, from Jacques message, gtk+ is thread safe, while tcl/tk is not.
> > 
> > Now i don't know if that helps a lot. Personnally i don't use threads when
> > writing GUIs, and am still strugling with modules and functors for it ...
> 
> This helps when you build network applications: you naturally want to
> have multiple threads, and having to route all GUI calls through a
> single thread is a pain.
> 
> Remark however that lablgtk does not really use gtk's (partial)
> thread-safety: caml programs use a central lock anyway. The difference
> is that lablgtk's code is reentrant, and camltk/labltk code is not
> (due to a large number of tables to handle callbacks). But gtk's
> re-entrance may come handy at some other time.

did you look at the thread code in mlgtk ? is it very different from what you do ? 

Friendly,

Sven Luther