OCaml's long range graphical direction?

OCaml's long range graphical direction?

[Daniel Ortmann]

Xavier,

Please speculate on the future development direction of graphical support
in OCaml.

Do you anticipate both Tk and GTk being supported?

Do you anticipate GTk support being ultimately more desirable and supported
than Tk?  If so, what are some of the reasons?

To what degree does threading affect the answer?

--
Daniel Ortmann, IBM Circuit Technology, Rochester, MN 55901-7829
ortmann@us.ibm.com / internal 8.553.6795 / external 507.253.6795
ortmann@isl.net home 507.288.7732

"The answers are so simple, and we all know where to look,
but it's easier just to avoid the question." -- Kansas

Re: OCaml's long range graphical direction?

[Xavier Leroy]

> Xavier,
> Please speculate on the future development direction of graphical support
> in OCaml.
> Do you anticipate both Tk and GTk being supported?
> Do you anticipate GTk support being ultimately more desirable and supported
> than Tk?  If so, what are some of the reasons?

I'm definitely the wrong person to ask, since I have never written a
full GUI for a program in all my life :-)  Other members of the OCaml
development team are much more qualified to answer your questions.

Still, let me play pointy-haired boss and comment on things I don't
fully understand.

I expect the Caml-TK interface to be supported (and included in the
standard OCaml distribution) for quite a while, but not actively
developed.  TK itself is quite stable and is available for many
platforms: Unix, Windows, and MacOS.  TK does well what it's been
designed to do: write quickly simple GUIs.  It starts to break apart
for really complex GUIs, as the development of the MMM Web browser
demonstrated.

I've heard lots of good things about GTK, and it looks more powerful
than TK, so it might be the wave of the future.  However, it is my
impression that the Windows port of GTK is lagging behind.  Also, the
Caml-GTK interface is still actively developed and hence might be less
stable than the Caml-TK interface.

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

If multithreading is a requirement, OCaml could probably cope with it
using the "systems" thread library.

Let us hear what other members of this list think about this.

- Xavier Leroy

Re: OCaml's long range graphical direction?

[Sven LUTHER]

On Tue, Feb 06, 2001 at 10:28:42AM +0100, Xavier Leroy wrote:
> > Xavier,
> > Please speculate on the future development direction of graphical support
> > in OCaml.
> > Do you anticipate both Tk and GTk being supported?
> > Do you anticipate GTk support being ultimately more desirable and supported
> > than Tk?  If so, what are some of the reasons?
> 
> I'm definitely the wrong person to ask, since I have never written a
> full GUI for a program in all my life :-)  Other members of the OCaml
> development team are much more qualified to answer your questions.
> 
> Still, let me play pointy-haired boss and comment on things I don't
> fully understand.
> 
> I expect the Caml-TK interface to be supported (and included in the
> standard OCaml distribution) for quite a while, but not actively
> developed.  TK itself is quite stable and is available for many
> platforms: Unix, Windows, and MacOS.  TK does well what it's been
> designed to do: write quickly simple GUIs.  It starts to break apart
> for really complex GUIs, as the development of the MMM Web browser
> demonstrated.
> 
> I've heard lots of good things about GTK, and it looks more powerful
> than TK, so it might be the wave of the future.  However, it is my
> impression that the Windows port of GTK is lagging behind.  Also, the

Err, i don't think so, haven't tried it though, don't own a windows box to
play with it, nor am i in the mood to invest in microsoft developpment tools.

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.

> 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 somethign for the new ocaml consortium ?

Apart from that, i think that for most usage, the current gtk+ bindings are
quite ok.

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.

It would be nice to know who is using which of the bindings and what is their
opinion on it ?

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.

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

But then again, this is work that need to be done, and i personnaly don't have
the time for it.

That said, i guess there is place in the ocaml world for both a tcl/tk binding
and a gtk+ one. Both are aimed at different uses, and well, as Pierre said the
tcl/tk bindings are not so much work, as they are following a stable tcl/tk.
(well sortof, don't know exactly what it's status is with regard of the
different tcl/tk versions. is anything above 8.0 supported ?)

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

> If multithreading is a requirement, OCaml could probably cope with it
> using the "systems" thread library.
> 
> Let us hear what other members of this list think about this.

Ok, this was my opinion, ...

Friendly,

Sven Luther

Re: OCaml's long range graphical direction?

[Pierre Weis]

[...]
> > I expect the Caml-TK interface to be supported (and included in the
> > standard OCaml distribution) for quite a while, but not actively
> > developed.

The original Camltk (which is slightly different from labl/tk) is also
used and supported by Jun and me. It is stable and works very well.

As Xavier mentioned (and as the Caml examples at
http://pauillac.inria.fr/caml/Examples/oc/camltk demonstrate) Caml/tk
is a must for simple GUIs (with a slightly simpler than MMM way of
abusing of the text widget).

[...]

> and a gtk+ one. Both are aimed at different uses, and well, as
> Pierre said the tcl/tk bindings are not so much work, as they are
> following a stable tcl/tk.  (well sortof, don't know exactly what
> it's status is with regard of the different tcl/tk versions. is
> anything above 8.0 supported ?)

Camltk is maintained up to date: it works also with the 8.3 version of
tcl/tk, including for the Caml Light version of the library.

[Personnal alleluia and auto compliment]
The Caml team's support to Caml users is decidedly incredibly good:
we effectively maintain what we promised to maintain :)

> > > 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 ...
> Sven Luther

As Sven, I don't use threads for writing GUIs.

Friendly,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/

Re: OCaml's long range graphical direction?

[Sven]

On Wed, Feb 07, 2001 at 10:30:10PM +0100, Pierre Weis wrote:
> [...]
> > > I expect the Caml-TK interface to be supported (and included in the
> > > standard OCaml distribution) for quite a while, but not actively
> > > developed.
> 
> The original Camltk (which is slightly different from labl/tk) is also
> used and supported by Jun and me. It is stable and works very well.
> 
> As Xavier mentioned (and as the Caml examples at
> http://pauillac.inria.fr/caml/Examples/oc/camltk demonstrate) Caml/tk
> is a must for simple GUIs (with a slightly simpler than MMM way of
> abusing of the text widget).

I think this is a preocupation of various people, not only is there need to choose between gtk+ or tcl/tk, but also there is need to choose between various implementation of the bindings.

But then choice is good :)))

The only problem is that it involves more work to maintain all of them.

> > and a gtk+ one. Both are aimed at different uses, and well, as
> > Pierre said the tcl/tk bindings are not so much work, as they are
> > following a stable tcl/tk.  (well sortof, don't know exactly what
> > it's status is with regard of the different tcl/tk versions. is
> > anything above 8.0 supported ?)
> 
> Camltk is maintained up to date: it works also with the 8.3 version of
> tcl/tk, including for the Caml Light version of the library.

Ok, ...

i think i will look at it, and take ownership of the camltk debian package, which seems to be no more maintained and very old indeed. it still requires 8.0.

Friendly,

Sven Luther

Re: OCaml's long range graphical direction?

[Jacques Garrigue]

As current maintainer of LablTk and LablGTK, I try to answer a bit on
these questions. But do not expect a real vision from me: what will
stay is what people are using, that seems enough for me. And if people
want to see more development on LablTk and/or CamlTk, I would see
nothing wrong in it.

Also, since somebody suggest me that more publicity could be good,
there is now a lablgtk mailing list. See info on the lablgtk home
page: http://wwwfun.kurims.kyoto-u.ac.jp/soft/olabl/lablgtk.html

> On Tue, Feb 06, 2001 at 10:28:42AM +0100, Xavier Leroy wrote:
[disclaimer erased]
> > I expect the Caml-TK interface to be supported (and included in the
> > standard OCaml distribution) for quite a while, but not actively
> > developed.  TK itself is quite stable and is available for many
> > platforms: Unix, Windows, and MacOS.  TK does well what it's been
> > designed to do: write quickly simple GUIs.  It starts to break apart
> > for really complex GUIs, as the development of the MMM Web browser
> > demonstrated.

I'm not sure it really breaks apart: to me MMM was rather successfull.
But it is difficult to completely control the look-and-feel of an
application with Tcl/Tk, and the weakness of the thread support may be
a problem for some specific uses (including a web browser).
And as often pointed out, not everybody agrees with the direction
Tcl/Tk is going to (strong investment on scripting).

A small correction: there is currently no support for the MacOS
version with Caml. No idea of how difficult it would be, but there was
no huge demand for it.

> > I've heard lots of good things about GTK, and it looks more powerful
> > than TK, so it might be the wave of the future.  However, it is my
> > impression that the Windows port of GTK is lagging behind.  Also, the

It is there, this is already a lot :-)
And some lablgtk applications are already ported to windows.

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?

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

> 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.
Or would it be possible to build a mlgtk compatible layer on top of
lablgtk's non-object layer?

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

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

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

Cheers,

Jacques Garrigue
---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>

Re: OCaml's long range graphical direction?

[Sven]

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

Re: OCaml's long range graphical direction?

[Claudio Sacerdoti Coen]

On Thu, Feb 08, 2001 at 08:55:55 +0100, Sven wrote:
> Who is using lablgtk and who is still using mlgtk ?

 Project HELM in Bologna was using mlgtk and then moved to lablgtk.
 The reasons are:

  1. lablgtk is a complete binding, while mlgtk is (was?) not and we
     had to add some missing parts
  2. the OO layer of lablgtk is a bit disappointing at the beginning,
     but after a while it appears to be more high-level and so
     better to use
  3. the two binding are equally undocumented

 This said, I still miss of mlgtk

  1. the easy layer for very rapid prototyping
  2. writing a new binding was easier

					Cheers,
					C.S.C.

-- 
----------------------------------------------------------------
Real name: Claudio Sacerdoti Coen
Graduate Computer Science Student at University of Bologna
Now at INRIA (Sophia-Antipolis, France)
E-mail: sacerdot@cs.unibo.it
http://caristudenti.cs.unibo.it/~sacerdot
----------------------------------------------------------------

Re: OCaml's long range graphical direction?

[Sven LUTHER]

On Fri, Feb 09, 2001 at 09:47:51AM +0100, Claudio Sacerdoti Coen wrote:
> On Thu, Feb 08, 2001 at 08:55:55 +0100, Sven wrote:
> > Who is using lablgtk and who is still using mlgtk ?
> 
>  Project HELM in Bologna was using mlgtk and then moved to lablgtk.
>  The reasons are:
> 
>   1. lablgtk is a complete binding, while mlgtk is (was?) not and we
>      had to add some missing parts

Due to lack of time ...

and also some people wrote bindings but never contributed them back to us
:(((

>   2. the OO layer of lablgtk is a bit disappointing at the beginning,
>      but after a while it appears to be more high-level and so
>      better to use
>   3. the two binding are equally undocumented
> 
>  This said, I still miss of mlgtk
> 
>   1. the easy layer for very rapid prototyping

Well, i think it could easily be ported, it is not a huge file after all.

>   2. writing a new binding was easier

This comes from 2. before.

Friendly,

Sven Luther

Re: OCaml's long range graphical direction?

[Brian Rogoff]

On Thu, 8 Feb 2001, Jacques Garrigue wrote:
> From: Sven LUTHER <luther@dpt-info.u-strasbg.fr>
> > 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 :-)
> 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.

I just hack on the examples, but surely a bit more documentation would
help. This might be good Consortium work, or even fixable with a volunteer 
effort. 

After all of the admonitions against the use of Obj.magic it's a bit
disconcerting to count 41 Obj.magic usages in lablgtk. I recall
hearing that that will change. What's the plan?

-- Brian

Re: OCaml's long range graphical direction?

[Jacques Garrigue]

From: Brian Rogoff <bpr@best.com>
> > This convoluted class and method system is intended to make using
> > lablgtk easier on the long term :-)
> > 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.
> 
> I just hack on the examples, but surely a bit more documentation would
> help. This might be good Consortium work, or even fixable with a volunteer 
> effort. 

Any volunteers ? Currently I have no time for documentation, sorry.
By the way, we can discuss that on the lablgtk list.

> After all of the admonitions against the use of Obj.magic it's a bit
> disconcerting to count 41 Obj.magic usages in lablgtk. I recall
> hearing that that will change. What's the plan?

Do not forget that any "external" declaration also amounts to an
Obj.magic, and there are 955 of them in lablgtk.
Seriously, most Obj.magic in lablgtk amount to a cast of an external
after checking its validity, and I see no way to avoid that.
What should disappear after ocaml 3.01 is release is the use of
     external coerce ... = "%identity"
which is an equivalent of Obj.magic used to go around some limitations
of the type system. There are 24 of them, but they will not be needed
anymore thanks to variance annotations in types.

Jacques
---------------------------------------------------------------------------
Jacques Garrigue      Kyoto University     garrigue at kurims.kyoto-u.ac.jp
		<A HREF=http://wwwfun.kurims.kyoto-u.ac.jp/~garrigue/>JG</A>

Re: OCaml's long range graphical direction?

[Brian Rogoff]

On Fri, 9 Feb 2001, Jacques Garrigue wrote:
> From: Brian Rogoff <bpr@best.com>
> > After all of the admonitions against the use of Obj.magic it's a bit
> > disconcerting to count 41 Obj.magic usages in lablgtk. I recall
> > hearing that that will change. What's the plan?
> 
> Do not forget that any "external" declaration also amounts to an
> Obj.magic, and there are 955 of them in lablgtk.

OK, you're right, I deserved that :-)

> Seriously, most Obj.magic in lablgtk amount to a cast of an external
> after checking its validity, and I see no way to avoid that.

Sure, but it seems to me that even if such things are implemented 
with Obj.magic under the hood we ought to come up with new names and 
eventually move "approved and safe usages" to the Sys module. I am 
probably under the influence of Modula-3 and Ada here...

> What should disappear after ocaml 3.01 is release is the use of
>      external coerce ... = "%identity"
> which is an equivalent of Obj.magic used to go around some limitations
> of the type system. There are 24 of them, but they will not be needed
> anymore thanks to variance annotations in types.

Cool, but you also write in another message 

> The last problem is how to stay type safe when you load a text file.
> Basically this means that you will be more verbose, and that will
> compare badly with guile-gtk or python-gtk based applications.

I think for this problem we need some dynamic typing in the language. It 
seems the Clean and Mercury languages have or will adopt such a solution; 
I don't know about Haskell. This is the same issue as with safe
marshalling right, so we are told that there is some help on the way.  

> So, there might be something to do, but I'm not so much convinced it
> will help with a language like ocaml.

Then ocaml will have to become like something else. It won't be the
first time. 

-- Brian

Re: OCaml's long range graphical direction?

[Jacques Garrigue]

Hi Brian,

From: Brian Rogoff <bpr@best.com>
> On Fri, 9 Feb 2001, Jacques Garrigue wrote:
> > Seriously, most Obj.magic in lablgtk amount to a cast of an external
> > after checking its validity, and I see no way to avoid that.
> 
> Sure, but it seems to me that even if such things are implemented 
> with Obj.magic under the hood we ought to come up with new names and 
> eventually move "approved and safe usages" to the Sys module. I am 
> probably under the influence of Modula-3 and Ada here...

I checked again the cases, and they really amount to changing types
according to the dynamic type of some C value.  Since C has no dynamic
typing, we cannot go very far...
But you're right, this number could be considerably reduced by making
specialized versions of Obj.magic specifying a bit more about the
input and output type.  I just avoided that, in case people would
start using this function as a safe one.

> > The last problem is how to stay type safe when you load a text file.
> > Basically this means that you will be more verbose, and that will
> > compare badly with guile-gtk or python-gtk based applications.
> 
> I think for this problem we need some dynamic typing in the language. It 
> seems the Clean and Mercury languages have or will adopt such a solution; 
> I don't know about Haskell. This is the same issue as with safe
> marshalling right, so we are told that there is some help on the way.  

Dynamic typing will still have a syntactic overhead. My point is that
a typed language should have its own better ways to do things easy
to do in scripting languages, and they can be different.

> > So, there might be something to do, but I'm not so much convinced it
> > will help with a language like ocaml.
> 
> Then ocaml will have to become like something else. It won't be the
> first time. 

I'm not sure of what you mean by that, but if you want to do things
like add downcast to ocaml, then this is a discussion we had several
years ago.  Even if dynamic typing is introduced, it will probably
have a more type dispatching flavor, forcing (or helping) the
programmer to write exhaustive code.

The credo of type safety can be hard to follow at times. But
abandoning it just to be like other languages will not make us
progress.  We already know that at least for pure ML programming
(including interfacing to many external libraries), one can find
strongly typed ways to work.  If using some external tool creates
problem with that, I personally will prefer rethinking the external
tool (or the way to use it), rather than forget that credo.

It may seem like fanatism for the type religion, but for me ocaml is
really that: a _typed_ language.

Jacques

Re: OCaml's long range graphical direction?

[Marcin 'Qrczak' Kowalczyk]

Fri, 09 Feb 2001 10:28:01 +0900, Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> pisze:

> which is an equivalent of Obj.magic used to go around some limitations
> of the type system. There are 24 of them, but they will not be needed
> anymore thanks to variance annotations in types.

What are variance annotations in OCaml?

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK

Re: OCaml's long range graphical direction?

[Nicolas barnier]

Marcin 'Qrczak' Kowalczyk wrote:
> 
> What are variance annotations in OCaml?

Perniciously stolen on the OCaml CVS server (file "Changes"), but I lack
the new doc ;-):

Objective Caml 3.01:
--------------------

New language features:
- Variables are allowed in "or" patterns, e.g.
     match l with [t] | [_;t] -> ... t ...
- "include <structure expression>" to re-export all components of a
  structure inside another structure.
- Variance annotation on parameters of type declarations, e.g.
    type (+'a,-'b,'c) t (covariant in 'a, contravariant in 'b, invariant in 'c)

-- Nicolas

Re: OCaml's long range graphical direction?

[Jacques Garrigue]

From: Nicolas barnier <barnier@recherche.enac.fr>
> Marcin 'Qrczak' Kowalczyk wrote:
> > 
> > What are variance annotations in OCaml?
> 
> Perniciously stolen on the OCaml CVS server (file "Changes"), but I lack
> the new doc ;-):
> 
> Objective Caml 3.01:
> --------------------
> 
> New language features:
> - Variables are allowed in "or" patterns, e.g.
>      match l with [t] | [_;t] -> ... t ...
> - "include <structure expression>" to re-export all components of a
>   structure inside another structure.
> - Variance annotation on parameters of type declarations, e.g.
>     type (+'a,-'b,'c) t (covariant in 'a, contravariant in 'b, invariant in 'c)

Yes, this is the syntax.
Practically, this means that you can now mix object and variant
subtyping with both datatypes and abstract types.

For instance, suppose that you have two types c and d, d subtype of c.
In ocaml 3.00, to coerce a list of d's to a list of c's, you would
have to write
     List.map (fun x -> (x : d :> c)) l
In ocaml 3.01, you can do it directly
     (l : d list :> c list)
because list is a covariant type, which you can see from its definition.

Not only that, but thanks to explicit variance annotations, even
abstract datatypes, like maps from the Map module, can be traversed by
subtyping.
My remark on a lesser need for "hacked" coercions is a side-effect of
that.

Jacques Garrigue

[Caml-list] Re: OCaml's long range graphical direction?

[Sven LUTHER]

On Tue, Feb 13, 2001 at 08:47:05AM +0900, Jacques Garrigue wrote:
> From: Nicolas barnier <barnier@recherche.enac.fr>
> > Marcin 'Qrczak' Kowalczyk wrote:
> > > 
> > > What are variance annotations in OCaml?
> > 
> > Perniciously stolen on the OCaml CVS server (file "Changes"), but I lack
> > the new doc ;-):
> > 
> > Objective Caml 3.01:
> > --------------------
> > 
> > New language features:
> > - Variables are allowed in "or" patterns, e.g.
> >      match l with [t] | [_;t] -> ... t ...
> > - "include <structure expression>" to re-export all components of a
> >   structure inside another structure.
> > - Variance annotation on parameters of type declarations, e.g.
> >     type (+'a,-'b,'c) t (covariant in 'a, contravariant in 'b, invariant in 'c)
> 
> Yes, this is the syntax.
> Practically, this means that you can now mix object and variant
> subtyping with both datatypes and abstract types.
> 
> For instance, suppose that you have two types c and d, d subtype of c.
> In ocaml 3.00, to coerce a list of d's to a list of c's, you would
> have to write
>      List.map (fun x -> (x : d :> c)) l
> In ocaml 3.01, you can do it directly
>      (l : d list :> c list)
> because list is a covariant type, which you can see from its definition.
> 
> Not only that, but thanks to explicit variance annotations, even
> abstract datatypes, like maps from the Map module, can be traversed by
> subtyping.
> My remark on a lesser need for "hacked" coercions is a side-effect of
> that.

Are there any papers on the subject available ?

Friendly,

Sven Luther
-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr

Re: OCaml's long range graphical direction?

[Alan Schmitt]

Actually, I just tried using GTK on windows yesterday, and it seems to
be fully functional (I'm just having trouble raising windows, but it
certainly is because I'm a beginner with this api).

>> I've heard lots of good things about GTK, and it looks more powerful
>> than TK, so it might be the wave of the future.  However, it is my
>> impression that the Windows port of GTK is lagging behind.  Also, the
>
>Err, i don't think so, haven't tried it though, don't own a windows box to
>play with it, nor am i in the mood to invest in microsoft developpment tools.

I must point out here that I did not use any Microsoft development
tool to write my program. I just got emacs, and mingw32 gcc (a gcc that
can generate easily win32 native code, which is recommended by the
gimp/gtk for windows web page). It worked fine, out of the box.

I haven't tried running lablgtk on windows, because I only have ocaml
installed for cygwin, not natively (and gtk is more problematic to use
with cygwin). Also, since I'm developping an application that is to be
used on machines where cygwin is not installed, it would mean one more
dll to add to the binary (and I'm not even thinking about license
issues ;-)

Amicalement,

Alan Schmitt

--
The hacker: someone who figured things out and made something cool happen.

Re: OCaml's long range graphical direction?

[bcpierce]

> Actually, I just tried using GTK on windows yesterday, and it seems to
> be fully functional (I'm just having trouble raising windows, but it
> certainly is because I'm a beginner with this api).

Unison (http://www.cis.upenn.edu/~bcpierce/unison) has a fairly
sophisticated GUI written on top of lablgtk, with help at the beginning
from Jacques Garrigue, who ported it from our Tk version.  We have lots
of users who run it on Windows with no problem.

There have been some annoyances with developing for Windows, but in
general things work fine.

     B

     

Re: OCaml's long range graphical direction?

[Dale Arntson]

Correct me if I'm wrong about this. I believe GTK+ is reentrant. TK is
not. This can make a difference with regard to the ease and pleasure of
developing gui applications. From an emacs editor, you can only interact
with a reentrant gui application.

- Dale Arntson

Xavier Leroy wrote:
> 
> > 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.
> 
> If multithreading is a requirement, OCaml could probably cope with it
> using the "systems" thread library.
> 
> Let us hear what other members of this list think about this.
> 
> - Xavier Leroy

Re: OCaml's long range graphical direction?

[John Max Skaller]

Xavier Leroy wrote:
> 
> > Xavier,
> > Please speculate on the future development direction of graphical support
> > in OCaml.

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

	No. Tk is not re-entrant/thread-safe and never will be.
(I'm paraphrasing Ousterhout's own claim).

	When 'normal' functions are called, one can always use a 
global lock to get around this problem, but this is not the case
for a GUI like Tk, which takes control of the system and
invokes user code _entirely_ using callbacks. When another
thread also invokes the Tk mainloop, all hell breaks loose,
since state data is held in static storage. It does no
good to use a lock, since the first thread never regains
control, and so the second will be excluded permanently.

	As far as I know, GTK has been built with an eye
to making it multi-threadable .. later (that is, it suffers
the same problem as Tk at present). MS-Windows is miles ahead here.

	One 'solution' to this problem is to have a single
'GUI' server thread, and have all client threads 'post'
to that server. Server callbacks can use locking to update
shared locations.  Unfortunately, this requires construction
of a complete client-side binding of the API to create a queue
of service requests, and a server side binding to pick them
up from within the event dispatch loop during idle time
and process them. [And event handling is event harder ... ]

	Note that Tcl (8.xx) is multi-threadable, since state
data can be captured in interpreter objects, of which there
can be many (at least one per thread ..).

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: OCaml's long range graphical direction?

[Francois Rouaix]

Okay, my 2 bits on this dicussion; (my credentials are : original designer of 
the CamlTk interface, writer of MMM. More recently, I've used CamlTk for a 
production tool in the company I work for).

I actually think that none of CamlTk/LablTK/LabelGTK fit the most common need 
in GUI development. In many cases, it still strikes me as utterly boring and 
time consuming to write *code* to put up menus, buttons, dialogs and such. Of 
course, from time to time, when you need some form of widget that is a bit 
original, programming will be useful. But that doesn't happen a lot, unless 
you write something that needs complex rendering or interaction.
Back in 1985, Apple started using resources to define interfaces. More 
recently, Palm used resources again to define interfaces. More recently, 
Mozilla folks used XML based representation (XUL) to define interfaces, with a 
GUI level scripting language (JavaScript/ECMAScript).
This type of approach has, in theory, lots of advantages
  - forces separation GUI from logic in the code
  - allows non-programmers to do the GUI design/layout (maybe using 
interactive tools in the process).
  - themes easily abstracted
  - language independence, extensibility, device independence

I wish that XUL wasn't so bloated (it's basically the whole Mozilla), and that 
I had time to play with it.
I would also be interested to know if anybody has explored this realm.

--f

Re: OCaml's long range graphical direction?

[Sven LUTHER]

On Thu, Feb 08, 2001 at 12:01:29PM -0800, Francois Rouaix wrote:
> Okay, my 2 bits on this dicussion; (my credentials are : original designer of 
> the CamlTk interface, writer of MMM. More recently, I've used CamlTk for a 
> production tool in the company I work for).
> 
> I actually think that none of CamlTk/LablTK/LabelGTK fit the most common need 
> in GUI development. In many cases, it still strikes me as utterly boring and 
> time consuming to write *code* to put up menus, buttons, dialogs and such. Of 
> course, from time to time, when you need some form of widget that is a bit 
> original, programming will be useful. But that doesn't happen a lot, unless 
> you write something that needs complex rendering or interaction.
> Back in 1985, Apple started using resources to define interfaces. More 
> recently, Palm used resources again to define interfaces. More recently, 
> Mozilla folks used XML based representation (XUL) to define interfaces, with a 
> GUI level scripting language (JavaScript/ECMAScript).
> This type of approach has, in theory, lots of advantages
>   - forces separation GUI from logic in the code
>   - allows non-programmers to do the GUI design/layout (maybe using 
> interactive tools in the process).
>   - themes easily abstracted
>   - language independence, extensibility, device independence
> 
> I wish that XUL wasn't so bloated (it's basically the whole Mozilla), and that 
> I had time to play with it.
> I would also be interested to know if anybody has explored this realm.

Well, you can do almost the same thing using ocaml modules and functors, which
gives you a good reason to use programing for GUI design.

Basically it goes liek that :

You have one module, which builds the interface.

Then you have a functor, which takes the the callbacks code as parameter and
does the attching of the callbacks to the interface and provides the main GUI
function.

an incomplete example can be found at :

ftp://lambda.u-strasbg.fr/vwck-20010125_1721.tgz

(it provides also some lablgtk + lablgl example, and is GPLed code)

Friendly,

Svne Luther

Re: OCaml's long range graphical direction?

[Jacques Garrigue]

Salut Francois,

> I actually think that none of CamlTk/LablTK/LabelGTK fit the most
> common need in GUI development. In many cases, it still strikes me
> as utterly boring and time consuming to write *code* to put up
> menus, buttons, dialogs and such. Of course, from time to time, when
> you need some form of widget that is a bit original, programming
> will be useful. But that doesn't happen a lot, unless you write
> something that needs complex rendering or interaction.  Back in
> 1985, Apple started using resources to define interfaces. More
> recently, Palm used resources again to define interfaces. More
> recently, Mozilla folks used XML based representation (XUL) to
> define interfaces, with a GUI level scripting language
> (JavaScript/ECMAScript).
> This type of approach has, in theory, lots of advantages
>   - forces separation GUI from logic in the code
>   - allows non-programmers to do the GUI design/layout (maybe using 
> interactive tools in the process).
>   - themes easily abstracted
>   - language independence, extensibility, device independence

In fact, the gnome project has a GUI builder called glade, which
allows one to produce either C code or an XML representation of the
interface. There is even a library libglade which allows one to
dynamically load such an XML representation and use it in a program.

It would be pretty easy to either interface to this library, or, more
interestingly, build a parser and interpreter for it, so as to be able
to use glade's output in lablgtk or mlgtk programs.
We had more grandiose projects with lablgtk, including creating a real
GUI builder, allowing to input directly Caml code in the interface
design, but this is lots of work for a volunteer effort, so the glade
approach could be a good future direction.

Still, I'm not sure I would use it personally. Basically, when I write
a lablgtk application, the code is not in the GUI layout: this is just
one line per widget. It is in all the callbacks and dynamic
processing.  I'm not so sure a GUI builder will help you a lot with
that, because it can also get in your way.

Another aspect is that separating GUI from logic is sometimes going
against modularity. The object-oriented widget approach takes the
widget as a unit for both GUI and logic, which helps in building
programs from parts.  Gtk also handles themes at the widget level.

The last problem is how to stay type safe when you load a text file.
Basically this means that you will be more verbose, and that will
compare badly with guile-gtk or python-gtk based applications.

So, there might be something to do, but I'm not so much convinced it
will help with a language like ocaml.

Amicalement,

Jacques

Re: OCaml's long range graphical direction?

[Jerome Vouillon]

On Fri, Feb 09, 2001 at 06:49:01PM +0900, Jacques Garrigue wrote:
> In fact, the gnome project has a GUI builder called glade, which
> allows one to produce either C code or an XML representation of the
> interface. There is even a library libglade which allows one to
> dynamically load such an XML representation and use it in a program.
> 
> It would be pretty easy to either interface to this library,

I don't think it would be a good idea to interface to this library, as
it is designed for C, which does not have higher-order function (so,
the library assumes that there is one function by call-back).

> or, more
> interestingly, build a parser and interpreter for it, so as to be able
> to use glade's output in lablgtk or mlgtk programs.

For the parser, one can just use PXP.  The interpreter is a lot of
work though...  Some time ago, I started to write one, but it only
supports a few widgets yet.

> Still, I'm not sure I would use it personally. Basically, when I write
> a lablgtk application, the code is not in the GUI layout: this is just
> one line per widget. It is in all the callbacks and dynamic
> processing.  I'm not so sure a GUI builder will help you a lot with
> that, because it can also get in your way.

I disagree.  When designing an interface, there are a lot of tweakings
(frame widths, alignements, ...) which are easily done using an
interface builder but much more tedious to program (and you often need
to recompile a lot of time to get them right).

> The last problem is how to stay type safe when you load a text file.
> Basically this means that you will be more verbose, and that will
> compare badly with guile-gtk or python-gtk based applications.

I get some code that look like this.  This does not look that verbose to me.

  let select_date w0 date cont =
    let gl = interface () in
    let (w, ctx) =
      create_dialog gl "choix de la date"
        ["valider",
         any (fun ctx _ _ ->
                (toplevel ctx)#destroy (); w0#misc#set_sensitive true;
                let (year, month, day) = (calendar ctx "calendrier")#date in
                cont {day = day; month = month + 1; year = year});
         "annuler",
         any (fun ctx _ _ ->
                (toplevel ctx)#destroy (); w0#misc#set_sensitive true)]
    in
    w0#misc#set_sensitive false;
    w#set_transient_for w0;
    begin match date with
      None -> ()
    | Some d ->
        let c = calendar ctx "calendrier" in
        c#select_month (d.month - 1) d.year;
        c#select_day d.day
    end;
    w#show ()

-- Jerome

Re: OCaml's long range graphical direction?

[Jacques Garrigue]

I'm moving this thread to the lablgtk mailing, since it is becoming
specific; please remove caml-list from follow-ups. People interested
who are not on the list may see messages on the lablgtk home page.

From: Jerome Vouillon <Jerome.Vouillon@inria.fr>

> On Fri, Feb 09, 2001 at 06:49:01PM +0900, Jacques Garrigue wrote:
> > In fact, the gnome project has a GUI builder called glade, which
> > allows one to produce either C code or an XML representation of the
> > interface. There is even a library libglade which allows one to
> > dynamically load such an XML representation and use it in a program.
> > 
> > It would be pretty easy to either interface to this library,
> 
> I don't think it would be a good idea to interface to this library, as
> it is designed for C, which does not have higher-order function (so,
> the library assumes that there is one function by call-back).

Actually there are also mechanisms provided for interpreted languages.
And interfacing at a basic level is really easy. I added a preliminary
wrapper to lablgtk. Those with CVS access can get it now, and I will
make a snapshot soon.

> > or, more interestingly, build a parser and interpreter for it, so
> > as to be able to use glade's output in lablgtk or mlgtk programs.
> 
> For the parser, one can just use PXP.  The interpreter is a lot of
> work though...  Some time ago, I started to write one, but it only
> supports a few widgets yet.

Yes, and liblglade already interprets for you.
In fact the radtest pure caml approach might be better than that,
since it means that the GUI builder will also be specialized for
caml code, with types and higher-order functions.
But this is lots of work.

> > Still, I'm not sure I would use it personally. Basically, when I write
> > a lablgtk application, the code is not in the GUI layout: this is just
> > one line per widget. It is in all the callbacks and dynamic
> > processing.  I'm not so sure a GUI builder will help you a lot with
> > that, because it can also get in your way.
> 
> I disagree.  When designing an interface, there are a lot of tweakings
> (frame widths, alignements, ...) which are easily done using an
> interface builder but much more tedious to program (and you often need
> to recompile a lot of time to get them right).

Notice that I was talking about myself.  For me this is basically a
TeX vs Word (or LyX), or MagicPoint vs PowerPoint choice.  I always
choose the programming style over the wysiwyg style, others have
different ways. (By the way people here always laugh at me because I
use the mouse with emacs rather than key sequences. Nobody is
perfect.)

For me, with a good toolkit you should not have to tweak that much
small parameters. And when I tweak them, I want means to change
different occurences simultaneously, which the GUI builder wouldn't
let me do.

> > The last problem is how to stay type safe when you load a text file.
> > Basically this means that you will be more verbose, and that will
> > compare badly with guile-gtk or python-gtk based applications.
> 
> I get some code that look like this.  This does not look that verbose to me.
> 
>   let select_date w0 date cont =
>     let gl = interface () in
>     let (w, ctx) =
>       create_dialog gl "choix de la date"
>         ["valider",
>          any (fun ctx _ _ ->
>                 (toplevel ctx)#destroy (); w0#misc#set_sensitive true;
>                 let (year, month, day) = (calendar ctx "calendrier")#date in
>                 cont {day = day; month = month + 1; year = year});
>          "annuler",
>          any (fun ctx _ _ ->
>                 (toplevel ctx)#destroy (); w0#misc#set_sensitive true)]
>     in
>     w0#misc#set_sensitive false;
>     w#set_transient_for w0;
>     begin match date with
>       None -> ()
>     | Some d ->
>         let c = calendar ctx "calendrier" in
>         c#select_month (d.month - 1) d.year;
>         c#select_day d.day
>     end;
>     w#show ()

Your code just demonstrates my point.  With a scripting language, you
would just write calendrier in place of (calendar ctx "calendrier").
And even with this extra verbosity, we have nothing more: typing is
still purely dynamic.
Also, the really hard part is not getting dynamically typed values in
a statically typed language, but the other way round. You cannot
export a callback written in lablgtk style, you have to conform to a
more uniform call syntax, because there is no direct way to get the
actual representation of a typed function.

Here is what I am thinking of doing:
* use libglade, because it already supports all gtk widgets
* extract from the xml file the types of all created widgets, and
  generate ml code to give you objects with the correct types.
  This just amounts to definitions like
       let calendrier = calendar ctx "calendrier"
  You only need to do generate it again when you add or remove
  widgets, not when you tweak parameters.
* leave callbacks completely on the ml side
  That is, only the layout is done by glade,
  everthing else uses lablgtk in the usual way.

This way type checking is dynamic, but happens completely at
initialization time, reducing need for tests.

I've tried thinking of a solution to export callback functions to
libglade, but I couldn't find an easy way to avoid completely dynamic
typing for them , which is something I detest. Imagine an ML program
in which you get a type error when you press a button.

Anybody has good ideas on how to allow writing callbacks with glade?

Jacques

Re: OCaml's long range graphical direction?

[Pierre Weis]

> I disagree.  When designing an interface, there are a lot of tweakings
> (frame widths, alignements, ...) which are easily done using an
> interface builder but much more tedious to program (and you often need
> to recompile a lot of time to get them right).
[...]
> -- Jerome

Those kind of tuning are easy to do when using some interactive system;
that's why we worked hard to provide interactive versions of our *tk
GUI, so that there is no need to recompile to only change some integer
value. Evidently, an interactive interface builder could also do the
same, but it is not necessary ...

Hope this helps,

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://pauillac.inria.fr/~weis/

Re: OCaml's long range graphical direction?

[John Max Skaller]

Francois Rouaix wrote:

> I actually think that none of CamlTk/LablTK/LabelGTK fit the most common need
> in GUI development. In many cases, it still strikes me as utterly boring and
> time consuming to write *code* to put up menus, buttons, dialogs and such. Of
> course, from time to time, when you need some form of widget that is a bit
> original, programming will be useful. But that doesn't happen a lot, unless
> you write something that needs complex rendering or interaction.
> Back in 1985, Apple started using resources to define interfaces. More
> recently, Palm used resources again to define interfaces. More recently,
> Mozilla folks used XML based representation (XUL) to define interfaces, with a
> GUI level scripting language (JavaScript/ECMAScript).

	Ah, but the specification of the resources is nothing more
than yet another programming language, and a seriously deficient one
usually (for example, not Turing complete).

	Furthermore, it is evident that this second programming language
must be _bound_ to the algorithmic one, and that binding is invariably
fragile and a serious problem.  That is, I think there is a downside
to separating functionality and appearance. As any serious game player
knows, the two are intimately connected.

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net