Does LablTk have a future?

Does LablTk have a future?

[Matt Gushee]

Hello, list members--

I've been thinking about GUI toolkits lately, and particularly Tk. I 
know there are a lot of people who believe Tk is dead, or should die. 
Personally, I'm not so sure. If you look at the features of Tk 8.5, and 
the development roadmap for future versions--perhaps it's too little, 
too late--but it is clear that the core Tcl/Tk developers are far from 
giving up. Indeed, they seem lately to have gotten a clue about what is 
needed to keep Tk a viable GUI toolkit.

Regardless of the status of Tk itself, LablTk seems to be going nowhere 
(note that I am not implying any criticism of the OCaml team--they have 
other, quite legitimate, priorities). It is poorly documented and is not 
keeping up with the recent improvements in Tk. Those who try to use it 
often run into trouble, and have difficulty getting their questions 
answered. Yet, for whatever reason, it remains the default GUI toolkit 
for OCaml.

I believe that Tk, while certainly not an ideal GUI, is still adequate 
for many applications, and if the above deficiencies are remedied, could 
still serve as OCaml's default GUI library for some time to come. And it 
occurs to me that, having several years' experience with Tk in various 
forms, and having studied much of the LablTk source code, I am in a 
position to do several things that might help revive LablTk. My purpose 
today is to inquire whether there is enough interest in the community to 
justify any or all of these projects. If there is, I am prepared to work 
on one or more of them--preferably with collaborators, but alone if 
necessary. If there is little or no interest, maybe it is time to 
consider (again) dropping LablTk entirely. Who wants to maintain code 
that isn't used or usable?

1) A Quick Reference

    This document would outline (with little or no explanation) the
    complete LablTk API, including all widget commands and the possible
    values of all LablTk-specific types. Currently the latter information
    can only be obtained by digging through the source code.

    Actually, I wrote a LablTk quick reference some time ago. It may need
    a bit of work, but no more than a couple of hours, I'm sure. So I
    *will* do this if there is any interest at all in it.

2) A Book

    This would be an in-depth tutorial on how to develop useful
    applications with LablTk. It would assume some programming
    experience, but it would not require advanced knowledge of OCaml, nor
    any knowledge of Tcl.

    I'm thinking to publish both a print edition and an inexpensive
    electronic edition. Though I need to research the costs a bit more, I
    believe I can offer the print edition--self-published using Print On
    Demand--at a reasonable price, comparable to what you pay for
    programming books at a bookstore (no, I don't hope to get rich off
    this--just to be modestly compensated for my efforts ;-).

3) A Community-based Modernization Project

    The idea here is to provide a Tk-based GUI library that is complete
    and in sync with the latest stable version of Tk. Other features that
    would be nice to have include (a) support for a few Tcl commands that
    are not strictly part of Tk, but are useful and commonly used in Tk
    programs--in particular I'm thinking of the 'after' command; and (b)
    a framework that allows downstream developers to create custom
    widgets with interfaces analogous to the builtin widgets. I'm not
    sure if (b) is feasible or not within the constraints of the OCaml
    type system--I've tried and failed in the  past--but I imagine
    there's some way to do it.

    Two other interrelated questions are whether this project should be
    done in parallel with LablTk or as a replacement, and whether the
    LablTk API should be preserved or something new designed. But it's
    probably not necessary to decide these questions immediately.

I eagerly await your comments.

--
Matt Gushee
Englewood, CO, USA

Re: [Caml-list] Does LablTk have a future?

[Matt Gushee]

Francois Rouaix wrote:

> I'm not active in the LablTk or CamlTk community anymore, but as the 
> writer of the (probably) largest piece of CamlTk code lying around (the 
> MMM browser), I want to let you know to feel free to pilfer code from 
> MMM, if useful or relevant.

Thanks!

> Also, you mention "extra Tcl" commands such as "after". I remember after 
> and timers to be present in CamlTk. Maybe they weren't ported to LablTk.

Yes, I think that's right. I wrote an app about a year ago that needed 
'after'. Though for some reason I can't recall, I didn't want to use the 
CamlTk version verbatim, I did model my implementation after it.

--
Matt Gushee
Englewood, CO, USA

Re: [Caml-list] Does LablTk have a future?

[Jon Harrop]

On Sunday 28 August 2005 16:38, Matt Gushee wrote:
> Regardless of the status of Tk itself, LablTk seems to be going nowhere

It is odd that you should bring this up now. I've spent the past week writing 
a simple database for a new veterinary surgery in OCaml using labltk. I had 
tried lablgtk before but failed to get to grips with it. By comparison, the 
labktk examples explained everything that I needed and I had a decent GUI up 
and running within a few hours.

May I add another question to this thread: What do people think of OCaml's GUI 
libraries in terms of stability?

> 1) A Quick Reference
>
>     This document would outline (with little or no explanation) the
>     complete LablTk API, including all widget commands and the possible
>     values of all LablTk-specific types. Currently the latter information
>     can only be obtained by digging through the source code.
>
>     Actually, I wrote a LablTk quick reference some time ago. It may need
>     a bit of work, but no more than a couple of hours, I'm sure. So I
>     *will* do this if there is any interest at all in it.

I haven't used anything exotic (or even non-trivial) but it seems to me that 
the API is already so simple that there isn't really a need for a quick 
reference.

> 2) A Book
>
>     This would be an in-depth tutorial on how to develop useful
>     applications with LablTk. It would assume some programming
>     experience, but it would not require advanced knowledge of OCaml, nor
>     any knowledge of Tcl.
>
>     I'm thinking to publish both a print edition and an inexpensive
>     electronic edition. Though I need to research the costs a bit more, I
>     believe I can offer the print edition--self-published using Print On
>     Demand--at a reasonable price, comparable to what you pay for
>     programming books at a bookstore (no, I don't hope to get rich off
>     this--just to be modestly compensated for my efforts ;-).

I think labltk is too specific to be commercially viable. Also, unless I've 
missed some hidden complexities in Tk programming, I think you'd have a job 
filling enough pages to call the result a book.

However, I would be very interested in a book that described how to write GUIs 
using OCaml. I'm still learning how to write and factor "conventional" GUI 
code in OCaml. I have also written custom GUIs using OpenGL (via lablGL) and 
OCaml is superb for this task.

As I'm the author of the only existing self-published book on OCaml, you may 
be interested to know that it is doing well (~500UKP per month for 6 months 
so far). So I would recommend that other people take the plunge and write 
more books on OCaml.

> 3) A Community-based Modernization Project
>
>     The idea here is to provide a Tk-based GUI library that is complete
>     and in sync with the latest stable version of Tk. Other features that
>     would be nice to have include (a) support for a few Tcl commands that
>     are not strictly part of Tk, but are useful and commonly used in Tk
>     programs--in particular I'm thinking of the 'after' command; and (b)
>     a framework that allows downstream developers to create custom
>     widgets with interfaces analogous to the builtin widgets. I'm not
>     sure if (b) is feasible or not within the constraints of the OCaml
>     type system--I've tried and failed in the  past--but I imagine
>     there's some way to do it.
>
>     Two other interrelated questions are whether this project should be
>     done in parallel with LablTk or as a replacement, and whether the
>     LablTk API should be preserved or something new designed. But it's
>     probably not necessary to decide these questions immediately.

I think it would be more constructive to create a decent cross-platform GUI 
library from the ground up for FPLs/OCaml. This wouldn't need to be anything 
fancy, just easy access to the simplest GUI elements to start with. I'd like 
to see GUIs described by purely functional data structures. I'm still 
factoring my current code so I'll let you know what I come up with. Also, 
despite GUI code being a pedagogical example for OO, I'm not yet convinced 
that OO adds anything useful.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Does LablTk have a future?

[Matt Gushee]

Jon Harrop wrote:

>>Regardless of the status of Tk itself, LablTk seems to be going nowhere 
> 
> It is odd that you should bring this up now. I've spent the past week writing 
> a simple database for a new veterinary surgery in OCaml using labltk. I had 
> tried lablgtk before but failed to get to grips with it. By comparison, the 
> labktk examples explained everything that I needed and I had a decent GUI up 
> and running within a few hours.

Yes, it does have that simplicity about it.

>>1) A Quick Reference

> I haven't used anything exotic (or even non-trivial) but it seems to me that 
> the API is already so simple that there isn't really a need for a quick 
> reference.

Well, you need some source of information other than the OCaml manual. 
To give just one example, if you want to do anything serious with 
Listbox widgets, you need to know the Listbox.index type, which isn't 
described in the manual.

Now, I have lately realized that you can explore LablTk with 
ocamlbrowser, so a reference doc isn't strictly necessary. But you could 
say the same about any OCaml module ... anyway, the document mostly 
exists, and some people may find it more convenient/pleasant to use a 
Web page or a printed document.

>>2) A Book

> I think labltk is too specific to be commercially viable.

Specific in what sense? And do you mean LablTk as a tool, or as a book 
topic?

> Also, unless I've 
> missed some hidden complexities in Tk programming, I think you'd have a job 
> filling enough pages to call the result a book.

Ever used the Canvas or Text widgets? There's a lot going on there. 
Besides, there are several mainstream (i.e. published by major tech 
publishers and available in any well-stocked bookstore) books about Tk 
programming (including at least Tcl/Tk, Perl/Tk and Tkinter). They've 
mostly been available for several years, so there must be some market 
for them.

Of course--and as an author/publisher, I'm sure you know this--the 
questions of what to write about, and how and how much, depend a great 
deal on the audience.

I can tell you that when I read _Effective Tcl/Tk Programming_ in about 
'98, when my GUI-coding experience was limited to a few toy apps in 
Visual Basic, I found it tremendously useful, with its in-depth 
explanation and extended examples of the more complex widgets, geometry 
managers, and the event handling mechanism. Properly described, it was a 
book about GUI programming *with* Tk, rather than strictly about Tk itself.

Maybe today's OCamlers are by and large beyond needing that sort of 
book. But it's kind of self-defeating to take for granted that the 
status quo will continue. I'm inclined to think that as OCaml gains in 
popularity--as it is certainly doing--there will be more people who need 
more hand-holding. Which doesn't necessarily mean there's much of market 
for a book such as I've proposed, just that I see some reason to hope.

> However, I would be very interested in a book that described how to write GUIs 
> using OCaml.

That might indeed be a good thing. I don't think, in my current state of 
knowledge, I'm the one to write it.

> As I'm the author of the only existing self-published book on OCaml, you may 
> be interested to know that it is doing well (~500UKP per month for 6 months 
> so far).

Well, at 85 quid a pop, I should think so (what is that in US money, 
about $120?)! But you're targeting an audience that has significant 
institutional support. I doubt very much that any and all OCaml books 
can be sold for that kind of money.

>>3) A Community-based Modernization Project

> I think it would be more constructive to create a decent cross-platform GUI 
> library from the ground up for FPLs/OCaml.

Great idea! But it sounds to me like the kind of thing that will never 
get finished.

> This wouldn't need to be anything 
> fancy, just easy access to the simplest GUI elements to start with.

What kind of apps do you envision writing with only the simplest elements?

> I'd like to see GUIs described by purely functional data structures. I'm
> still factoring my current code so I'll let you know what I come up with.
> Also, despite GUI code being a pedagogical example for OO, I'm not yet
 > convinced that OO adds anything useful.

Agreed. Once I too was among the benighted souls, those who worship the 
false god of OO. But then I saw the functional light, and I was saved! 
Amen, brother!

Thanks for the comments. Lots of good food for thought there.

--
Matt Gushee
Englewood, CO, USA

Re: [Caml-list] Does LablTk have a future?

[Yaron Minsky]

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]

On 8/30/05, Matt Gushee <mgushee@havenrock.com> wrote:
> 
> 
> Maybe today's OCamlers are by and large beyond needing that sort of
> book. But it's kind of self-defeating to take for granted that the
> status quo will continue. I'm inclined to think that as OCaml gains in
> popularity--as it is certainly doing--there will be more people who need
> more hand-holding. Which doesn't necessarily mean there's much of market
> for a book such as I've proposed, just that I see some reason to hope.


I haven't the faintest idea what the market for such a thing would be, but 
if a good book on using Tk from OCaml existed, I would buy it. Similarly for 
a Gtk/Ocaml book.

y

[-- Attachment #2: Type: text/html, Size: 989 bytes --]

Re: [Caml-list] Does LablTk have a future?

[Jon Harrop]

On Tuesday 30 August 2005 05:39, Matt Gushee wrote:
> Now, I have lately realized that you can explore LablTk with
> ocamlbrowser, so a reference doc isn't strictly necessary. But you could
> say the same about any OCaml module ... anyway, the document mostly
> exists, and some people may find it more convenient/pleasant to use a
> Web page or a printed document.

Yes, I've only studied it through ocamlbrowser. So I'd recommend simply 
commenting the labltk .mli file rather than writing a quick reference.

> >>2) A Book
> >
> > I think labltk is too specific to be commercially viable.
>
> Specific in what sense? And do you mean LablTk as a tool, or as a book
> topic?

I meant that the topic "GUI programming using lablTK" is too specific for a 
book.

> > Also, unless I've
> > missed some hidden complexities in Tk programming, I think you'd have a
> > job filling enough pages to call the result a book.
>
> Ever used the Canvas or Text widgets? There's a lot going on there.

I'm using the Text widget in a very simple way. I may have to start using the 
canvas widget because I can't figure out how to do various things (e.g. a 
spreadsheet).

> Besides, there are several mainstream (i.e. published by major tech
> publishers and available in any well-stocked bookstore) books about Tk
> programming (including at least Tcl/Tk, Perl/Tk and Tkinter). They've
> mostly been available for several years, so there must be some market
> for them.

Yes and there are a few books on OCaml. But you're talking about the 
intersection of those two sets of users, which is much smaller.

> Maybe today's OCamlers are by and large beyond needing that sort of
> book. But it's kind of self-defeating to take for granted that the
> status quo will continue. I'm inclined to think that as OCaml gains in
> popularity--as it is certainly doing--there will be more people who need
> more hand-holding. Which doesn't necessarily mean there's much of market
> for a book such as I've proposed, just that I see some reason to hope.

Yes, that is true.

> > As I'm the author of the only existing self-published book on OCaml, you
> > may be interested to know that it is doing well (~500UKP per month for 6
> > months so far).
>
> Well, at 85 quid a pop, I should think so (what is that in US money,
> about $120?)! But you're targeting an audience that has significant
> institutional support. I doubt very much that any and all OCaml books
> can be sold for that kind of money.

Yes. As OCaml gains popularity it will be commercially viable to publish 
cheaper books. In the mean time, if you're interested in making money, 
perhaps educational software would be better?

> > This wouldn't need to be anything
> > fancy, just easy access to the simplest GUI elements to start with.
>
> What kind of apps do you envision writing with only the simplest elements?

I have two projects with GUIs now. One is that database app, that has a very 
simple GUI. The other is Presenta, that draws its own GUI via OpenGL.

I tried to get the latter to work with lablgtk but was told to take my 
question to the gtk forum, where they told me not to use out of date OpenGL 
bindings.

Incidentally, OpenGL is extremely important for us. So a GUI toolkit must be 
able to handle OpenGL widgets. Indeed, this begs the question: why not do the 
whole thing in OpenGL?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Does LablTk have a future?

[David MENTRE]

Hello,

2005/8/30, Jon Harrop <jon@ffconsultancy.com>:
> Incidentally, OpenGL is extremely important for us. So a GUI toolkit must be
> able to handle OpenGL widgets. Indeed, this begs the question: why not do the
> whole thing in OpenGL?

Because printing and PDF rendering is not easy. And because you loose
the ability to have native interface on all paltforms (Gnome, KDE,
Windows 2k, Windows XP, MacOS X, ...).

As somebody else pointed out, the ocaml binding to Cairo library could
be used as underlying framework but you still don't have native
platform GUI style.

Maybe it would be worth putting up a mailing list and a wiki instead
of bothering 500+ caml-list readers? Anybody has easy access to such
facility?

Yours,
d.

Re: [Caml-list] Does LablTk have a future?

[Jon Harrop]

On Tuesday 30 August 2005 13:22, David MENTRE wrote:
> 2005/8/30, Jon Harrop <jon@ffconsultancy.com>:
> > Incidentally, OpenGL is extremely important for us. So a GUI toolkit must
> > be able to handle OpenGL widgets. Indeed, this begs the question: why not
> > do the whole thing in OpenGL?
>
> Because printing and PDF rendering is not easy.

Why do you think that?

> And because you loose 
> the ability to have native interface on all paltforms (Gnome, KDE,
> Windows 2k, Windows XP, MacOS X, ...).

Yes but we gain the ability to have a better interface on all platforms.

> As somebody else pointed out, the ocaml binding to Cairo library could
> be used as underlying framework

I'd rather go entirely OCaml except for the lowest level stuff. Writing 
bindings is just too tedious and error prone and I'm not convinced that 
there's anything sophisticated enough out there that it would be worth the 
hassle. We can certainly improve upon Cairo and I have only had bad 
experiences with other widget sets (e.g. Qt, wxWindows).

> but you still don't have native platform GUI style.

It might be nice to allow native GUI dialog boxes (e.g. load and save) but, 
beyond that, I'd be happy to have non-native provided it was more aesthetica 
than the native GUIs.

Also, we'd need the library to be free for commercial use.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Does LablTk have a future?

[David MENTRE]

Jon,

2005/8/30, Jon Harrop <jon@ffconsultancy.com>:
> > [me]
> > Because printing and PDF rendering is not easy.
> 
> Why do you think that?

Hmm. I thought that making postscript or pdf output of an OpenGL
document is difficult, but apparently I'm wrong.

> > And because you loose
> > the ability to have native interface on all paltforms (Gnome, KDE,
> > Windows 2k, Windows XP, MacOS X, ...).
> 
> Yes but we gain the ability to have a better interface on all platforms.

Well, "better" is rather subjective. And not having the native
interface means that people will say "oh, look, this is a non-standard
OCaml program" instead on looking at the application itself.

That's said, if we can have a nice (to be defined ;-) OCaml GUI
toolkit, cross-platform and well documented, we a minimal set of tools
to help design interfaces, I would seriously consider its use.

> Also, we'd need the library to be free for commercial use.

I'm usually a proponent of GPL but for such a toolkit, I wouldn't mind
a LGPL or BSD-like license.

I have created a Google group to discuss this:
Homepage:  	   	http://groups.google.com/group/ocaml-gui  	 
Group email: 	  	ocaml-gui@googlegroups.com 	 
Description: 	  	Mailing list to discuss design and development of a
cross-platform Graphic User Interface for the OCaml language


Yours,
d.

Re: [Caml-list] Does LablTk have a future?

[Jon Harrop]

On Tuesday 30 August 2005 16:47, David MENTRE wrote:
> 2005/8/30, Jon Harrop <jon@ffconsultancy.com>:
> > Why do you think that?
>
> Hmm. I thought that making postscript or pdf output of an OpenGL
> document is difficult, but apparently I'm wrong.

Yes, generating PS from OpenGL is very easy (I've done a lot of work on this 
for Presenta, of course).

> > Yes but we gain the ability to have a better interface on all platforms.
>
> Well, "better" is rather subjective. And not having the native
> interface means that people will say "oh, look, this is a non-standard
> OCaml program" instead on looking at the application itself.

True. I think this is the lesser of evils though.

> That's said, if we can have a nice (to be defined ;-) OCaml GUI
> toolkit, cross-platform and well documented, we a minimal set of tools
> to help design interfaces, I would seriously consider its use.

Absolutely. Me too.

> > Also, we'd need the library to be free for commercial use.
>
> I'm usually a proponent of GPL but for such a toolkit, I wouldn't mind
> a LGPL or BSD-like license.

If it is OCaml then it will have to be statically compiled in, so you'd need 
that LGPL get-out clause.

> I have created a Google group to discuss this:
> Homepage:  	   	http://groups.google.com/group/ocaml-gui
> Group email: 	  	ocaml-gui@googlegroups.com
> Description: 	  	Mailing list to discuss design and development of a
> cross-platform Graphic User Interface for the OCaml language

I'll cross post this message...

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Does LablTk have a future?

[Matt Gushee]

Jon Harrop wrote:

 >>> Yes but we gain the ability to have a better interface on all 
platforms.
 >>
 >>
 >> Well, "better" is rather subjective. And not having the native
 >> interface means that people will say "oh, look, this is a non-standard
 >> OCaml program" instead on looking at the application itself.
 >
 >
 >
 > True. I think this is the lesser of evils though.


Hmm, I'd like to think so. Jef Raskin[*] wrote something to the effect 
that we need better interfaces than what we have now, and something 
better will necessarily be different--with which I heartily agree.

But in terms of "industry acceptance" in the near term ... I've been 
involved in a number of discussions of why Tk is awful (or not), and one 
point that always comes up is that users allegedly don't like Tk apps 
because they look different.

-- 
Matt Gushee
Englewood, CO, USA

Re: [Caml-list] Does LablTk have a future?

[Matt Gushee]

Matt Gushee wrote:

> Hmm, I'd like to think so. Jef Raskin[*] wrote something to the effect 
> that we need better interfaces than what we have now, and something 
> better will necessarily be different--with which I heartily agree.

And the footnote is:

[*] Sometimes called the "father of the Macintosh," Raskin has more
     recently developed an innovative UI originally called The Humane
     Interface, now known as Archie (or aRCHIe?).

Re: [Caml-list] Does LablTk have a future?

[Matt Gushee]

Matt Gushee wrote:

> [*] Sometimes called the "father of the Macintosh," Raskin has more
>     recently developed an innovative UI originally called The Humane
>     Interface

Whoops, that was the title of his book. The software was called The 
Humane *Environment.* And Raskin unfortunately left this world in early 
2005, but his work is being carried on by his son.

--
Matt Gushee
Englewood, CO, USA

Re: [Caml-list] Does LablTk have a future?

[Chris Campbell]

On 01/09/05, Matt Gushee <mgushee@havenrock.com> wrote:
> 
> Hmm, I'd like to think so. Jef Raskin[*] wrote something to the effect
> that we need better interfaces than what we have now, and something
> better will necessarily be different--with which I heartily agree.
> 
> But in terms of "industry acceptance" in the near term ... I've been
> involved in a number of discussions of why Tk is awful (or not), and one
> point that always comes up is that users allegedly don't like Tk apps
> because they look different.


That's why I was concerned about the development of a gui with regards
to windows and osx.  If it doesn't look like Aqua, if it doesn't look
like Windows it's not going to work.

Once you factor in feel you might as well forget it, especially on
OSX.  People are less than enthusiastic about X apps on OSX.  They
don't behave like Aqua apps and don't follow Mac conventions. 
Similarly with GTk on windows without skinning.

I also don't see a point in reinventing the wheel.  For Linux someone
could probably do better than KDE/Gnome/Enlightenment given a couple
of years, and some might actually use it but no one is gonna like it
on OSX or Windows (which is used by most people).

The best option is to write a high level toolkit over a gui and make
it general enough to use the native gui.  Let's face it, most systems
have buttons, windows, etc and they serve the same purpose on all
systems even if they don't look or behave the same on all systems. 
It's only the api that's different from a programmers perspective and
as programmers that's where the problem is.  Don't turn a problem for
programmers into a problem for users, because they're the ones who
decides the popularity of your software in the end.

Paul Graham wrote about the problems programmers have seeing it from
the user perspective, but I'm not sure which article it is... might be
"Revenge of the nerds".


Chris

Re: Does LablTk have a future?

[Bardur Arantsson]

Jon Harrop wrote:
> On Tuesday 30 August 2005 13:22, David MENTRE wrote:
> 
>>2005/8/30, Jon Harrop <jon@ffconsultancy.com>:
>>
>>>Incidentally, OpenGL is extremely important for us. So a GUI toolkit must
>>>be able to handle OpenGL widgets. Indeed, this begs the question: why not
>>>do the whole thing in OpenGL?
>>
[--snip--]

>>And because you loose 
>>the ability to have native interface on all paltforms (Gnome, KDE,
>>Windows 2k, Windows XP, MacOS X, ...).
> 
> 
> Yes but we gain the ability to have a better interface on all platforms.
> 

Nonsense. For special cases it may appear that writing a GUI toolkit is 
easy. What everbody seems to forget whenever this discussion comes up is 
that writing a GUI toolkit that's useful for *general* use is hard. Very 
hard. You need to worry about such things as BiDi, accessibility, 
feel-compatibility with the "host" platform (ie. things like identical 
focus handling, interaction with other programs through DnD, etc. etc.), 
  proper widget design, etc. etc.

In short: The solution seems easy to you because you're only seeing a 
subset of the problem.

Just a small real life example of why not to do this: The Mozilla people 
wrote their own GUI toolkit and after all these years they *still* 
haven't been able to fix all the focus problems. (Note: They actually 
had valid reasons for doing so, among other things the fact that none of 
the GUI toolkits at the time could do some of the things required for 
full standards compliance.)

-- 
Bardur Arantsson
<bardur@imada.sdu.dk>
<bardur@scientician.net>

Dyslexic, agnostic insomniac: One who lies awake at night
wondering if there really is a dog.
                                                         Anonymous

Re: [Caml-list] Does LablTk have a future?

[David Thomas]

--- Jon Harrop <jon@ffconsultancy.com> wrote:
> > And because you loose the ability to have native 
> > interface on all paltforms (Gnome, KDE, Windows
2k, 
> > Windows XP, MacOS X, ...).
> 
> Yes but we gain the ability to have a better
> interface on all platforms.

While pleasantly egotistical, I would have to say that
this is a false statement.  Yes, there are problems
with any given windowing system.  Note, however, that
the user has already chosen the system whose
shortcomings they feel the most comfortable with.  

Additionally, they have likely already configured that
system according to their personal preferences, which
means that your application must either know about
each individual system and poll it for each relevent
setting, require the user to re-specify their
preferences with respect to your application, or
ignore the user's preferences altogether.  Since this
is something that virtually every application with a
windowed GUI will likely be using, it should be done
by a GUI library, rather than on an
application-by-application basis.

There's also the principle of least surprise.  While
your system may be better than theirs in the abstract,
the best GUI behaves the way the user expects it to
behave, and that means the same way that the user's
other applications behave - hence, native look and
feel when it doesn't conflict with other goals. 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Caml-list] Does LablTk have a future?

[Tyler Eaves]

Perhaps a viable solution is to take an approach similar to wxWindows, and  
write a library the uses a native library on each major platform (e.g.  
GTK2 or QT3 on *nix, GDI on Windows, and Cocoa on Mac OS X. This way you  
get a native interface on each paltform, as well as saving the effort of  
having to actually write a low-level toolkit. That was programming effort  
could be spent solely on the actual API.

-- 
Tyler Eaves
<tylere@mailshack.com>

Re: [Caml-list] Does LablTk have a future?

[Jon Harrop]

I had better clarify before continuing. I see two viable approaches here:

1. Write OCaml bindings to the native GUIs and then an OCaml wrapper that 
abstracts the nativeness away.

2. Write a new widget toolkit designed to render via OpenGL.

On Tuesday 30 August 2005 18:47, David Thomas wrote:
> ...

If we do (1) then it will handle skinning and the intersection of the sets of 
functionality of the native GUIs.

If we do (2) then customisation and skinning will be ignored but you have the 
advantage of real time 2D and 3D graphics.

Option (2) seems much easier and more useful to me. I've never cared about 
skinning...

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Does LablTk have a future?

[Chris Campbell]

[forgot to cc list]

On 30/08/05, Jon Harrop <jon@ffconsultancy.com> wrote:
>
> I had better clarify before continuing. I see two viable approaches here:
>
> 1. Write OCaml bindings to the native GUIs and then an OCaml wrapper that
> abstracts the nativeness away.
>
> 2. Write a new widget toolkit designed to render via OpenGL.
>

...

> If we do (1) then it will handle skinning and the intersection of the sets of
> functionality of the native GUIs.
>
> If we do (2) then customisation and skinning will be ignored but you have the
> advantage of real time 2D and 3D graphics.
>
> Option (2) seems much easier and more useful to me. I've never cared about
> skinning...

Easier???  You'd need to build a complete event/messaging subsystem, a
renderer, ..., a set of widgets and get people to ship it.  Plus it'd
likely only run on Linux and BSD.  What about OSX Mac/Windows?  It's
not easier at all especially if it was to be anything like a modern
day gui - think Quartz Extreme/Aqua or AeroGlass. IIRC the plan for
Gtk+ is to go this route too using Cairo.  Despite hating Gtk, it'd be
better to rely on them for the gui and wrap it with something like
your description of a "functional GUI" or bind to WxWidgets (or both).

There's also enlightenment as an alternative for Linux users.

Fwd: [Caml-list] Does LablTk have a future?

[Chris Campbell]

---------- Forwarded message ----------
From: Chris Campbell <cyberdanx@gmail.com>
Date: 30-Aug-2005 23:53
Subject: Re: [Caml-list] Does LablTk have a future?
To: Jon Harrop <jon@ffconsultancy.com>


On 30/08/05, Jon Harrop <jon@ffconsultancy.com> wrote:
>
> I had better clarify before continuing. I see two viable approaches here:
>
> 1. Write OCaml bindings to the native GUIs and then an OCaml wrapper that
> abstracts the nativeness away.
>
> 2. Write a new widget toolkit designed to render via OpenGL.
>

...

> If we do (1) then it will handle skinning and the intersection of the sets of
> functionality of the native GUIs.
>
> If we do (2) then customisation and skinning will be ignored but you have the
> advantage of real time 2D and 3D graphics.
>
> Option (2) seems much easier and more useful to me. I've never cared about
> skinning...

Easier???  You'd need to build a complete event/messaging subsystem, a
renderer, ..., a set of widgets and get people to ship it.  Plus it'd
likely only run on Linux and BSD.  What about OSX Mac/Windows?  It's
not easier at all especially if it was to be anything like a modern
day gui - think Quartz Extreme/Aqua or AeroGlass. IIRC the plan for
Gtk+ is to go this route too using Cairo.  Despite hating Gtk, it'd be
better to rely on them for the gui and wrap it with something like
your description of a "functional GUI" or bind to WxWidgets (or both).

There's also enlightenment as an alternative for Linux users.

Re: [Caml-list] Does LablTk have a future?

[Doug Kirk]

On Mac OS X, all UI elements are OpenGL textures and run on the  
graphics chip, courtesy of the OS (provided you have a recent machine).

Of course, you'd still need a nice system to build the library, but  
OpenGL on OS X is no problem at all :)



> On Aug 30, 2005, at 5:56 PM, Chris Campbell wrote:
>
> What about OSX Mac/Windows?
>

Re: Fwd: [Caml-list] Does LablTk have a future?

[Jon Harrop]

On Tuesday 30 August 2005 23:56, Chris Campbell wrote:
> > Option (2) seems much easier and more useful to me. I've never cared
> > about skinning...
>
> Easier???  You'd need to build a complete event/messaging subsystem, a
> renderer, ..., a set of widgets and get people to ship it.

Yes. The event system is trivial in OCaml (thanks to closures), particularly 
because graphics are regenerated on the fly for OpenGL. The renderer is as 
difficult as you want to make it. Conventional GUIs do little more than quads 
and pixmaps. Making widgets isn't exactly rocket science, albeit somewhat 
tedious. If by "ship it" you mean package it up for Debian etc. them I'm sure 
people will volunteer.

> Plus it'd likely only run on Linux and BSD.

No. It would run on Mac OS X and Windows as well. Probably others...

> It's 
> not easier at all especially if it was to be anything like a modern
> day gui - think Quartz Extreme/Aqua or AeroGlass.

I'm talking about aiming low.

> it'd be
> better to rely on them for the gui and wrap it with something like
> your description of a "functional GUI" or bind to WxWidgets (or both).

I disagree. Static type checking could be leveraged for GUI code as it is for 
most other OCaml code. Writing correct bindings to libraries like those is 
just as much work as writing a toolkit on top of OpenGL, only you'd end up 
with their inefficiencies and instabilities.

If anyone is seriously considering writing bindings for Cairo from OCaml then 
I'd like to know.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: Fwd: [Caml-list] Does LablTk have a future?

[Olivier Andrieu]

 Jon Harrop [Wednesday 31 August 2005] :
 > If anyone is seriously considering writing bindings for Cairo from
 > OCaml then I'd like to know.

Gah! they already exist : http://cairographics.org/cairo_2docaml

(No tarballs, only in the CVS repository).

-- 
   Olivier

Feeding the OCaml GUI troll (was: Re: [Caml-list] Does LablTk have a future?)

[David MENTRE]

Hello Jon,

2005/8/30, Jon Harrop <jon@ffconsultancy.com>:
> I had better clarify before continuing. I see two viable approaches here:
> 
> 1. Write OCaml bindings to the native GUIs and then an OCaml wrapper that
> abstracts the nativeness away.
> 
> 2. Write a new widget toolkit designed to render via OpenGL.
> 
> If we do (1) then it will handle skinning and the intersection of the sets of
> functionality of the native GUIs.
> 
> If we do (2) then customisation and skinning will be ignored but you have the
> advantage of real time 2D and 3D graphics.
> 
> Option (2) seems much easier and more useful to me. I've never cared about
> skinning...

Well, in option (1), as somebody else underlined it, it is a lot more
than just skinning. How do you handle i18n and l10n issues? How to
display bidirectionnal languages? How to write Arabic, Hebrew or
Chinese characters? How to take input in Japanese or Tamil? How to
handle copy/paste and drag & drop with other applications of the
platform? Or to print PDF with Arabic and Indian characters in the
same document?

Maybe you don't have those issues for you local market, Jon. But as
soon as you are writting graphical applications to be used worldwide,
those issues are coming out pretty quickly. This is at least a
requirement for my application.

I really fear your under estimate the amount of work needed to
accomplish such a job. And the OCaml community seems pretty fragmented
on this GUI front.

To improve on the situation, I see following options:

 1. improve Labgtk2 documentation and use Gtk2 on all patforms. As our
try on Win32 have shown, compiling Gtk2 on Windows seems pretty
complicated and a moving target, albeit not impossible to do. I don't
know for MacOS X. And Gtk2 behaviour is different on Win32 than native
Win32 applications;

 2. write a *simple* GUI front end, in OCaml, with only simple modules
and/or simple objects. No fancy use of OCaml type system. Stay close
to ML core. Use Labgtk2, native Win32 and MacOS X libraries to render
the GUI. However I don't know the complexity of handling gory details,
like encoding of strings;

 3. (Jon option) write a pure GUI from scratch, in pure OCaml. A
project similar to Qt or WxWidgets for C++. It seems doable to have a
basic GUI but handling all i18n and desktop interoperability issues
seems pretty complicated;

 4. Use Labltk. I can't really comment on it, as I have never used it
and can't say about its graphical behaviour or desktop integration
(copy/paste and drag&drop);

 5. drop OCaml to write GUI. Use other languages (usually C++) to make
front-ends and use OCaml code only as backend, communicating through
sockets or shared memory. Maybe the most viable long term solution.

Personnally, I don't know what decision to take. My current GUI code
is in Lablgtk2 but, as stated in other emails, use of Gtk2 is too
difficult for me. And I don't want to go into another reinvent the
wheel syndrom. (sigh)

Yours,
d.

Proposal a GUI from Ocamlsdl

[Christophe Raffalli]

I plan to write a real interface for GlSurf (google it !). And I might 
start a minimal GUI library on top of OcamlSDL.

What are the advantages:

- access to everything in the hardware: openGL, sound, CD player, ttf 
fonts, etc (can even play video it seems !)

- no need for callbacks from C to Caml (this is a pain, and you can not 
create too many callbacks with register_callback, if you do not want
performance problems. I add a lot of pb with that on Glut, an app with a 
lot of button and one registered callback per button seems not reasonable).
With OcamlSDL, you can have a Caml thread listening (or polling) the 
event queue and calling the Caml function directly.

- it seems simple to use (I write a small example in just a few minutes, 
despite the lack of documentation)

- works at least on windows, linux and OS X (aqua, no X11)

I can either do my interface alone in my corner with a minimal GUI 
library ... or we can start a project with a bunch of people ...

just a pb ... I do not know yet how to manipulate the OS X menu bar from 
SDL ... If someone knows how to do that ?

Re: [Caml-list] Proposal a GUI from Ocamlsdl

[Jon Harrop]

On Wednesday 31 August 2005 10:06, Christophe Raffalli wrote:
> I plan to write a real interface for GlSurf (google it !).

You're already famous.

> And I might start a minimal GUI library on top of OcamlSDL.

Excellent idea but how will you support Hebrew? ;-)

> I can either do my interface alone in my corner with a minimal GUI
> library ... or we can start a project with a bunch of people ...

I'd like to help. Do you have a scene graph with GL picking up and running?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] Proposal a GUI from Ocamlsdl

[Nathaniel Gray]

On 8/31/05, Jon Harrop <jon@ffconsultancy.com> wrote:
> On Wednesday 31 August 2005 10:06, Christophe Raffalli wrote:
> > I plan to write a real interface for GlSurf (google it !).
> 
> You're already famous.
> 
> > And I might start a minimal GUI library on top of OcamlSDL.
> 
> Excellent idea but how will you support Hebrew? ;-)

I think it's wise to learn to walk before trying to run.  If you try
to solve every issue in GUI design for version 1.0 then version 1.0
will never exist.

Cheers,
-n8

-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->

Re: Feeding the OCaml GUI troll (was: Re: [Caml-list] Does LablTk have a future?)

[Jon Harrop]

On Wednesday 31 August 2005 09:48, David MENTRE wrote:
> Well, in option (1), as somebody else underlined it, it is a lot more
> than just skinning. How do you handle i18n and l10n issues? How to
> display bidirectionnal languages? How to write Arabic, Hebrew or
> Chinese characters? How to take input in Japanese or Tamil? How to
> handle copy/paste and drag & drop with other applications of the
> platform? Or to print PDF with Arabic and Indian characters in the
> same document?

Those features would require a substantial amount of work for either (1) or 
(2), AFAIK.

> Maybe you don't have those issues for you local market, Jon. But as
> soon as you are writting graphical applications to be used worldwide,
> those issues are coming out pretty quickly. This is at least a
> requirement for my application.

Then your requirements are quite different from my own and, I believe, many 
other people's. To start with, I am just interested in a minimal working 
library that would let me knock up simple applications. Cross-platform drag 
and drop is way down the line...

> I really fear your under estimate the amount of work needed to
> accomplish such a job. And the OCaml community seems pretty fragmented
> on this GUI front.

If you're talking about supporting all languages and all features on all 
platforms then of course it is an enormous undertaking. From my point of 
view, that is such a difficult task that it simply isn't worth discussing. I 
believe we can only do a decent job if we attack a small problem.

> ...
>  3. (Jon option) write a pure GUI from scratch, in pure OCaml. A
> project similar to Qt or WxWidgets for C++. It seems doable to have a
> basic GUI but handling all i18n and desktop interoperability issues
> seems pretty complicated;

If you're talking about my option (2) then it is more like GLUI and not like 
Qt and wxWindows.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: Feeding the OCaml GUI troll

[Matt Gushee]

First of all, I hope the "troll" label is tongue-in-cheek. I really am 
not trying to stir up argument for argument's sake. The goal is to find 
a project or two that might benefit both myself and the community.

David MENTRE wrote:

> I really fear your under estimate the amount of work needed to
> accomplish such a job. And the OCaml community seems pretty fragmented
> on this GUI front.

Sounds right to me.

>  2. write a *simple* GUI front end, in OCaml, with only simple modules
> and/or simple objects. No fancy use of OCaml type system. Stay close
> to ML core. Use Labgtk2, native Win32 and MacOS X libraries to render
> the GUI. However I don't know the complexity of handling gory details,
> like encoding of strings;

I'm not sold on the idea of a "simple" GUI front end. I've tried one or 
two of them, and I think they're probably good for, say, a database 
application, but useless for more general apps like text editors and 
drawing tools.

>  4. Use Labltk. I can't really comment on it, as I have never used it
> and can't say about its graphical behaviour or desktop integration
> (copy/paste and drag&drop);

Drag and drop would have to be added; copy/paste functionality is a 
built-in feature of the Text widget and possibly some others.

>  5. drop OCaml to write GUI. Use other languages (usually C++) to make
> front-ends and use OCaml code only as backend, communicating through
> sockets or shared memory. Maybe the most viable long term solution.

That's no doubt a technically sound solution. Is it commercially viable? 
I'd say that depends on your market. Large organizations are generally 
comfortable with separately installed components. Small businesses, 
primary and secondary schools (at least in the US), and home users are 
often terrified of complex installation and configuration procedures. 
They want one-step installation.

--
Matt Gushee
Englewood, CO, USA

Re: [Caml-list] Re: Feeding the OCaml GUI troll

[skaller]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

On Wed, 2005-08-31 at 22:49 -0600, Matt Gushee wrote:

> I'm not sold on the idea of a "simple" GUI front end.

I am. My idea is this: GET RID OF CALLBACKS.
The idea is to use (user space) threads instead.

The big problem with GUI's is that they're passive.
You write 'event handlers' and have to store the current
state manually. By control inverting the code, you can
just use a thread for each widget.

For example for a button something like:

	let rec wait_down () =
		read event;
		match event with
		| state_request -> 
			send(up); 
			wait_down()
		| click -> wait_up()

	and wait_up () =
		draw_button_down();
		read event;
		match event with
		| state_request -> 
			send(down); 
			wait_up()
		| click ->
			draw_button_up()
			wait_down()


is purely functional: it uses the program counter
to maintain state, instead of a mutable state variable.		

-- 
John Skaller <skaller at users dot sourceforge dot net>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Re: Feeding the OCaml GUI troll

[David MENTRE]

Hello,

2005/9/1, skaller <skaller@users.sourceforge.net>:
> I am. My idea is this: GET RID OF CALLBACKS.
> The idea is to use (user space) threads instead.

The main issue with threads is that as soon as you want to share
state/data between threads, it becomes a mess. Of course, you can have
some clean tools like OCaml channels in module Event, but they don't
avoid issues like deadlocks.

The callback and main event handler scheme as the advantage of
simplicity: your program does only one thing at a time.

Yours,
d.

Re: [Caml-list] Re: Feeding the OCaml GUI troll

[skaller]

[-- Attachment #1: Type: text/plain, Size: 1886 bytes --]

On Thu, 2005-09-01 at 15:28 +0200, David MENTRE wrote:
> Hello,
> 
> 2005/9/1, skaller <skaller@users.sourceforge.net>:
> > I am. My idea is this: GET RID OF CALLBACKS.
> > The idea is to use (user space) threads instead.
> 
> The main issue with threads is that as soon as you want to share
> state/data between threads, it becomes a mess. 

Ah .. but read again: *user space* threads. Such as those
generated by Felix. They're C++, but a control inverter
for Ocaml shouldn't be too hard.

> The callback and main event handler scheme as the advantage of
> simplicity: your program does only one thing at a time.

Same as user space threads.

In Felix, something like this happens:

class f: public continuation {

f(caller, args) { 
	_caller = caller; 
	arg = args;
}

continuation *resume() {

	//read event
	switch (pc) { 
	...
		read_flag = true; 
		pe = &event; // where to put the event
		pc = 99;
		return this;
	case 99:
		
	// call subroutine(x)
		pc = 100;
		return new subroutine(this,x);
	case 100:
	...

	// return
		return _caller;

}
};


The driver loop is (crudely):

	while(p){
		p=p->resume();
		if(p->read_flag == true){
			p->pe = next_event();
			p->read_flag = false;
		}
	}

for a single thread. There's nothing here that can't
be done with an Ocaml class instead of a C++ one.

Probably, even with camlp4. The main problem is that
you can only yield when the machine stack is empty,
which means you HAVE to use continuations everywhere
you might want to read an event/yield.

MLton threads do this much better than Felix: they
use an MLton stack, not the machine stack,
and the MLton stack is kept linear using the
GC's compactor so it grows and shrinks *without*
losing linearity .. I wish I could do that in Felix.


-- 
John Skaller <skaller at users dot sourceforge dot net>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Re: Feeding the OCaml GUI troll

[Chris Campbell]

On 01/09/05, skaller <skaller@users.sourceforge.net> wrote:
> On Wed, 2005-08-31 at 22:49 -0600, Matt Gushee wrote:
> 
> > I'm not sold on the idea of a "simple" GUI front end.
> 
> I am. My idea is this: GET RID OF CALLBACKS.
> The idea is to use (user space) threads instead.
> 
> The big problem with GUI's is that they're passive.
> You write 'event handlers' and have to store the current
> state manually. By control inverting the code, you can
> just use a thread for each widget.

Joe Armstrong did something like this with Erlang and X called Ex11. 
Can't remember how it works exactly, but it seems each widget is a
thread and can process events independantly of the others.

http://www.erlang.se/workshop/2004/ex11.pdf

Re: [Caml-list] Re: Feeding the OCaml GUI troll

[Ville-Pertti Keinonen]

[-- Attachment #1: Type: text/plain, Size: 1732 bytes --]

On Thu, 2005-09-01 at 23:15 +1000, skaller wrote:

> I am. My idea is this: GET RID OF CALLBACKS.
> The idea is to use (user space) threads instead.
> 
> The big problem with GUI's is that they're passive.
> You write 'event handlers' and have to store the current
> state manually. By control inverting the code, you can
> just use a thread for each widget.

Have you actually done this in a GUI context, or do you just find it
conceptually attractive?

I've experimented with GUI concepts and event mechanisms in OCaml, and
created an event mechanism that could relatively easily be used in a
sort-of control inverted form by manually wrapping things into
continuations.  I never ended up making use of that form of events for
the actual low-level GUI functionality, because it always seemed easier
to just use methods or attach callbacks to events and use explicit
state.  Now that could simply be because I was sort-of porting a GUI
library that I had written earlier (in C++ and Scheme) and I'm rather
used to GUI mechanisms layered around inheritance (one of the few places
where it actually seems natural to me).

> For example for a button something like:
> 
> 	let rec wait_down () =
  ...

> 	and wait_up () =
  ...

> is purely functional: it uses the program counter
> to maintain state, instead of a mutable state variable.

But consider that the state of a button isn't quite that simple.
Tracking the state explicitly isn't difficult - attached is an actual
push button class implementation in a traditional imperative/OO style.

There's 3 boolean variables (8 states, although half of them are
impossible) tracked locally by the simplest stateful widget.  It also
has keyboard focus state, tracked by a superclass.


[-- Attachment #2: ws_button.ml --]
[-- Type: text/plain, Size: 2262 bytes --]

(* Push button type *)

open Ws_widget_types
open Ws_types

type events =
  [ Ws_swidget.events
  | `ButtonClicked ]

class ['a] t parent (style_init : Ws_style.button_style) =
  object (self)
    inherit ['a] Ws_swidget.t parent as super

    constraint 'a = [> events ]

    val style = style_init
    val mutable is_pressed = false
    val mutable is_down = false
    val mutable is_in = false

    method redraw d =
      let mode =
	if is_down then `ButtonPressed
	else
	  if is_active then
	    if is_in then `ActiveMouseOver else `Active
	  else
	    if is_in then `MouseOver else `Default
      in
	style#draw d mode

    method size_changed =
      style#set_size (r_size region)

    method enter_notify =
      is_in <- true;
      if is_pressed then
	is_down <- true;
      self#need_redraw

    method leave_notify =
      is_in <- false;
      if is_pressed then
	is_down <- false;
      self#need_redraw

    method button_press b p m =
      if b = 1 then
	begin
	  is_pressed <- true;
	  is_down <- true;
	  self#need_redraw
	end
      else
	super#button_press b p m

    method button_release b p m =
      if b = 1 then
	begin
	  if is_down && is_pressed then self#clicked;
	  is_pressed <- false;
	  is_down <- false;
	  self#need_redraw
	end
      else
	super#button_release b p m

    method clicked =
      self#post_event `ButtonClicked

    initializer
      let _ = self#request_notify ButtonNotify
      and _ = self#request_notify CrossingNotify in
	self#set_bg style#bg;
	self#bind_key (1, 0, (Ws_key.Kchar 32)) (fun _ -> self#clicked; true)
  end

let on_click f =
  function
      `ButtonClicked -> f ()
    | _ -> ()

let create ?region ?text ?label ?pos ?size ?onclick parent =
  let style = parent#get_app#style in
  let bs = style#button_style in
  let (bt : events t) = new t parent bs
  and set_opt f = function Some x -> f x | _ -> () in
    set_opt bt#set_pos pos;
    set_opt (fun f -> bt#connect (on_click f)) onclick;
    begin
      match text with
	  Some t -> bs#set_label (style#button_textlabel t)
	| None -> set_opt bs#set_label label
    end;
    set_opt bt#set_region region;
    if region = None then begin
      match size with
	  Some x -> bt#set_size x
	| None -> bt#set_size (bs#size_hint)
    end;
    bt

Re: [Caml-list] Re: Feeding the OCaml GUI troll

[skaller]

[-- Attachment #1: Type: text/plain, Size: 7934 bytes --]

On Fri, 2005-09-02 at 10:40 +0300, Ville-Pertti Keinonen wrote:
> On Thu, 2005-09-01 at 23:15 +1000, skaller wrote:
> 
> > I am. My idea is this: GET RID OF CALLBACKS.
> > The idea is to use (user space) threads instead.
> > 
> > The big problem with GUI's is that they're passive.
> > You write 'event handlers' and have to store the current
> > state manually. By control inverting the code, you can
> > just use a thread for each widget.
> 
> Have you actually done this in a GUI context, or do you just find it
> conceptually attractive?

I have done some brief experiments to check it can be
made to work .. but the real answer is no, it is only
a planned application (of Felix). But see below ..

> I've experimented with GUI concepts and event mechanisms in OCaml, and
> created an event mechanism that could relatively easily be used in a
> sort-of control inverted form by manually wrapping things into
> continuations.  I never ended up making use of that form of events for
> the actual low-level GUI functionality, because it always seemed easier
> to just use methods or attach callbacks to events and use explicit
> state. 

Yes, that seems likely for simpler low level things:
for example for a button (my example) clearly you just
need a boolean flag, which is pretty easy to maintain
manually.

However I *have* used the mechanism in a sophisticated embedded
environment, namely a telephony system.

We found, as above, that for some event handling,
callbacks were indeed better: some events like 
'phone call disconnected' are global, pervasive,
and in this case quite final.

Other events didn't fit so easily into this category.
Excuse brief explanation: the system used an asynchronous
real time data base. One task was to terminate a prepaid
phone call when the client's money ran out. In a place
like USA, where phone companies offer various deals,
and there are multiple time zones, the costing algorithm
can be quite complex -- especially if the client is
mobile (basically a recursive tree search with
pruning is required to find the minimum cost 'route')

To do this with hand written callback driven code is 
well nigh impossible. The algorithm is hard enough
written in a functional form with referential transparency
to help reason you have it right.

The fact the control inverted (event driven) form
is object oriented/procedural, yet equivalent to
a purely functional algorithm, makes mechanical
control inversion attractive -- but the utility
is only apparent in more complex examples.

>  Now that could simply be because I was sort-of porting a GUI
> library that I had written earlier (in C++ and Scheme) and I'm rather
> used to GUI mechanisms layered around inheritance (one of the few places
> where it actually seems natural to me).

I guess you start with simplistic procedural code, but
then find it is too hard to tailor and start using 
inheritance to help with that.

Unfortunately, a bit further down the track,
you again find it isn't good enough, and you need
much more dynamics -- and you have to switch
to delegation.

Further still, even that isn't dynamic enough,
and you start needing real message passing, that is,
posting events into the event queue as a means of
communicating between widgets.

The real question is, at this stage of sophistication,
whether you wouldn't be better off due to strong
static type checking, implementing stuff with functional
style instead: functional code can represent state too,
using closures.

I don't know the answer .. but I do know existing GUI's
are pretty bad. It is FAR too hard to get even simple
things to work, and hardly any GUI applications around
have any really high level functionality: the programmers
are struggling so hard to get really basic things to work.

> > For example for a button something like:
> > 
> > 	let rec wait_down () =
>   ...
> 
> > 	and wait_up () =
>   ...
> 
> > is purely functional: it uses the program counter
> > to maintain state, instead of a mutable state variable.
> 
> But consider that the state of a button isn't quite that simple.

The code was just an example of the style: for a more sophisticated
widget -- I mean lets go all the way and look at a tree widget,
an edit widget, or a canvas ... it isn't clear functional code
will be easier.

> Tracking the state explicitly isn't difficult 

No, not for a button. But for complex widgets it is.

Lets face it -- most programmers can't even get the mouse cursor
right. GQView, magnify/shrink with the mouse changes the mouse
from (+) to (-) when you next move the mouse .. which is plain
wrong (it should change as soon as you click to magnify or
shrink).

Many games .. mouse droppings (they got the double buffering
wrong).

So the fact is, programmers simply cannot manage trivial
state in a modern GUI correctly -- particularly they cannot
keep the user view of the state properly synchronised with
the internal state.

Interestingly I think Tk handles this quite well (it knows
when state is changed and re-renders the right things at
the right time automatically).

Windows is particularly BAD at some things, for example,
the tool used to edit the environment is utter rubbish:
PATH etc have very long string values and the dialog
box is small and fixed size .. this is just rubbish.

Another example: the ocamlbrowser is quite nice,
except it spawns top level windows left right and
centre, gets the size wrong, so every window has
to be adjusted. Any decent tool would allow you to spawn
those windows inside a pane or container of your choice:
modern 'Window managers' are just rubbish.

Sophisticated applications (eg Visual Studio) will give
you the choice .. but it is all hand programmed
for that particular application. I have designed a 
system called HWM (Hierarchical Window Manager) which
does away with that completely -- instead of a toolbar
you get a tree widget, which allows you to move windows
around in groups, and mutate their containers to any kind
you like (top level, panes, notebooks, etc). 

I have actually implemented this three separate times.
It relieves the programmer of the burned of hand coding
'mega-widgets' and leaves the organisation of widgets
up to the end user in a consistent way.

Of course .. this is a fairly radical concept .. the 
Open Source community would rather just copy Windows
and add minor improvements than bother to do any real
design work.

The real problem, IMHO, is C. You just cannot consider
new high level concepts for a GUI and implement them in C:
it is way too hard. 

Ocaml offers opportunities to do much better .. but there
is no point just copying existing GUIs: we already have
LablTk and LablGtk, which provide standard functionality
rewrapped more nicely. If we're going to do a real GUI
designed to take advantage of an advanced functional
programming language, we need to do a whole lot better
than what we already have .. and I do not see how to do this
without a lot of design work.

We do NOT want something with the same look and feel as
existing GUIs. They suck. But we have to have something
much better to be convincing .. do you remember the days
before Drag-and-Drop existed?

IMHO the *key* problem with GUI's -- and why real (TM) developers
hate using them -- is the lack of automation: unix script 
sucks, but it does provide automation. If we're going to make
a new GUI it has to have full automation capability.

The only way I can think of to do that is to base the 
core components of the GUI on Category Theory -- for example
have 'product' widgets and 'sum' widgets which represent
a collection and a set of alternatives, respectively,
and a standard way to combine them graphically.

-- 
John Skaller <skaller at users dot sourceforge dot net>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Re: Feeding the OCaml GUI troll

[Damien Bobillot]

[-- Attachment #1: Type: text/plain, Size: 2603 bytes --]

skaller wrote :

> IMHO the *key* problem with GUI's -- and why real (TM) developers
> hate using them -- is the lack of automation: unix script
> sucks, but it does provide automation. If we're going to make
> a new GUI it has to have full automation capability.

I totally agree : in software development, GUI programming is one of  
the most boring phases. According to my experience, the main issue is  
GUI to core program communication, you have to :
- programmatically get pointers to hundreds of GUI elements
- programmatically install event callbacks for the same widgets
- programmatically keep GUI element contents in synchronization with  
internal variables

All this stuff is very easy to do, but often long, boring.  
Fortunately, you don't any more need to programmatically define your  
widgets (and their attributes, position), thanks to WYSIWYG GUI  
creation tools (Qtdesigner for Qt, Apple's Interface Builder, Visual  
Studio...).

I think, the good idea is the automation of all this work. I'll give  
the solutions retained by Apple for Interface Builder :
- the global variables/class member containing reference to widgets  
are automatically set-up. You just have to define them in your code  
and tell the GUI creation tool to which widgets each variables is  
bind to.
- the user directly define the callbacks function in the GUI editor  
tool : you just have to give the name of the callback function.
- any class member may be bind to the content of a widget : if the  
user types characters in a text field, the matching class member (a  
variable of type string) is automatically updated to contain the  
newly typed characters. If the programmer modify the value of this  
variable, the text field is automatically updated to the new value of  
the variable. Several widgets may be bond to one variable, several  
variable to one widget, and even a variable/widget may be bond
to a file entry to enable persistent storage of the value (it's used  
for user preference storage). It's also possible to create  
transformers in order to do some type convertion when you use, for  
instance, a text field bond to a integer variable.

I don't know if it is implementable in ocaml as is, or if it is  
really the good solution (it has been designed for the Objective-C  
language, using some of its very particular features). However, I  
think it gives a good idea of what is missing in current GUI APIs and  
GUI creation tools.

Apple explanation of bindings :
http://developer.apple.com/cocoa/cocoabindings.html

-- 
Damien alias Schmurtz
aim:goim?screenname=schmuuurtz


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2375 bytes --]

Re: [Caml-list] Re: Feeding the OCaml GUI troll

[skaller]

[-- Attachment #1: Type: text/plain, Size: 2358 bytes --]

On Sat, 2005-09-03 at 12:34 +0200, Damien Bobillot wrote:
> skaller wrote :
[]
>  If the programmer modify the value of this  
> variable, the text field is automatically updated to the new value of  
> the variable. 

Actually, Tk has done this for years.

[]

> I don't know if it is implementable in ocaml as is, 

I don't see why not: the issue isn't implementation
but design.

The kind of automation you are talking about I'd consider
a kind of bi-reflection: changes to a value by the program
are reflected in the GUI, and changes to the GUI made
by the user are reflected in the program variables.

Actually my HWM (Hierarchical Window Manager) system
requires this in triplicate:

(a) There is a Tree data structure in memory representing
'containment' relations.

(b) At a higher level, these objects are concretely particular
widgets -- this level is hidden by abstraction from (a).

(c) The GUI widgets on the 'screen'.

So basically you can do things like: at level (a), you delete
a child from a parent and add it to another:

	p2.add_child(p1.remove_child(c))

and on the screen, the child c and its children move magically
from paned window p1 into a notebook, p2.

Similarly, if the user rips a child out of p1 and drops
it onto p2, the window is reparented .. which is reflected
in the abstraction (a) without programmer intervention.

The user can ALSO do this via the tree widget as well as
directly with the actual windows (recall, there is no toolbar,
instead a tree widget is used).

Thus, both the program AND the user can move window
groups around. Other operations include deletion,
iconisation, and transmuting a container from one kind to
another (eg paned window to notebook).

With HWM, the programmer is relieved of the tedium of 
high level organisation: it is left up to the client
to use the window manager. Combine this with low level
automation such as bi-reflection of variables and fields,
and we have a new kind of GUI.

My builds of HWM were all done with Object Oriented code.
I tend to think it functional code may be much better.
For example -- using persistence of Tree data structure,
it should be easy to 'undo' a reparenting operation.

Exactly how to do this I do not know .. :)

-- 
John Skaller <skaller at users dot sourceforge dot net>


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Caml-list] Re: Feeding the OCaml GUI troll

[Richard Jones]

We face a similar problem, connecting database fields to GUI widgets.
We came up with a concept of a "tied reference" variable.  Included
below is the interface - you can probably work out how it works.  It
has to be said that it wasn't particularly successful, and still
required lots of manual and repetitive work to make it happen.
Luckily we ditched that project for financial reasons :-)

Rich.

------------------------------------------------------------ tiedref.mli
(* Tied references.
 * Copyright (C) 2003 Merjis Ltd.
 * $Id: tiedref.mli,v 1.2 2003/12/02 13:22:01 rich Exp $
 *)

type 'a tiedref

val tiedref : read:(unit -> 'a) -> write:('a -> unit) -> 'a tiedref

val ( !* ) : 'a tiedref -> 'a
val ( *:= ) : 'a tiedref -> 'a -> unit

------------------------------------------------------------ dbtiedref.mli
(* Database-backed tied references.
 * Copyright (C) 2003 Merjis Ltd.
 * $Id: dbtiedref.mli,v 1.3 2004/03/08 13:44:25 rich Exp $
 *)

open Tiedref

type dbrow

val dbrow : Dbi.connection -> string -> string -> Dbi.sql_t list -> dbrow

type 'a dbfield

val dbfield_bool_not_null : string -> bool dbfield
val dbfield_bool : string -> bool option dbfield
val dbfield_int_not_null : string -> int dbfield
val dbfield_int : string -> int option dbfield
val dbfield_string_not_null : string -> string dbfield
val dbfield_string : string -> string option dbfield

val dbtiedref : dbrow -> 'a dbfield -> 'a tiedref


-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Caml-list] Re: Feeding the OCaml GUI troll

[yoann padioleau]

>
> IMHO the *key* problem with GUI's -- and why real (TM) developers
> hate using them -- is the lack of automation: unix script
> sucks, but it does provide automation. If we're going to make
> a new GUI it has to have full automation capability.
>

I am not sure I understand what you think by automation. But indeed  
what I like
with shell script is that I can automate some tasks over traditionnal  
programs (or even other scripts).
I can do some "for", "while" over programs, ...
That is because the interface of a command line is simpe,  stdin and  
stdout  with text as value.

But in fact there is some works do to the same with GUI. AppleScript  
is one such thing. You can do
script that send commands to apps and so you can automate some task.  
The problem is that the application
must be AppleScript aware, and that you have to know what it exports.

I once had a great idea,  "let's make the interface of a GUI  
application  be its interface" :)
That is let's be able to write in a sctipt:
  tell Musicplayer
    MENUBAR(OPEN("/tmp/staying-alive.mp3"))

Unfortunatly Apple already had the same idea,
http://www.apple.com/applescript/uiscripting/03.html




> The only way I can think of to do that is to base the
> core components of the GUI on Category Theory -- for example
> have 'product' widgets and 'sum' widgets which represent
> a collection and a set of alternatives, respectively,
>

Interesting, but it sounds like we have already this in current GUI  
toolkit (ok they dont use terms from category theory).
The product is called  boxing  in gtk (and tk I guess) and the sum is  
represented via the typing systems, the widget all inherits
from the same base class.

> and a standard way to combine them graphically.
>

Well you have vbox (vertical box) to pack them guess what,  
vertically,  and hbox.
And you have various options.



> -- 
> John Skaller <skaller at users dot sourceforge dot net>
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

Re: [Caml-list] Re: Feeding the OCaml GUI troll

[Jonathan Roewen]

If GUI research with OCaml in mind, then DST may be your kettle of
fish =) You get to start afresh, with nothing standing in your way for
design. Experimentation will be key.

We'll be needing a new GUI toolkit soon, once we have our new kernel
design built. Of course, you have the problems of no existing drawing
primitives (yet), or font support (yet).

One possible limitation: we may decide to use G'Caml, which I don't
believe has been ported to the 3.x series yet (think type-safe ocaml
IPC).

For those interested, please email me privately.

Jonathan Roewen

Re: [Caml-list] Re: Feeding the OCaml GUI troll

[Doug Kirk]

> But in fact there is some works do to the same with GUI.  
> AppleScript is one such thing. You can do
> script that send commands to apps and so you can automate some  
> task. The problem is that the application
> must be AppleScript aware, and that you have to know what it exports.
>

Actually, the application doesn't have to AppleScript (AS) aware. The  
only reason you augment an app with an AS dictionary is so that AS  
itself can correctly parse the syntax for the messages to the app at  
development time.

Remember that AS is really an interface to an underlying  
technology...the Apple Event mechanism. So, if you can speak low- 
level Apple Events, you don't  need AS at all.

See <http://developer.apple.com/documentation/mac/IAC/IAC-94.html>  
for instance.
Or <http://www.google.com/search?q=site:developer.apple.com+%22Apple 
+Events%22&ie=UTF-8&oe=UTF-8>

The point being, of course, that all of the visual UI re/actions are  
simply side-effects of the underlying event mechanism, which allows  
automation. I'd think you'd want that type of mechanism forming the  
basis of the GUI.

--doug

Re: [Caml-list] Re: Feeding the OCaml GUI troll

[Richard Jones]

On Fri, Sep 02, 2005 at 10:39:41PM +1000, skaller wrote:
> The fact the control inverted (event driven) form
> is object oriented/procedural, yet equivalent to
> a purely functional algorithm, makes mechanical
> control inversion attractive -- but the utility
> is only apparent in more complex examples.

Another good example where it makes sense is in writing web servers.
Have a look at the source to (event-driven webserver) BOA sometime -
it's absolutely horrible.

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: Feeding the OCaml GUI troll (was: Re: [Caml-list] Does LablTk have a future?)

[Nathaniel Gray]

On 8/31/05, David MENTRE <david.mentre@gmail.com> wrote:
> 
>  1. improve Labgtk2 documentation and use Gtk2 on all patforms. As our
> try on Win32 have shown, compiling Gtk2 on Windows seems pretty
> complicated and a moving target, albeit not impossible to do. I don't
> know for MacOS X. And Gtk2 behaviour is different on Win32 than native
> Win32 applications;

There is no native Gtk2 port for OS X.  Gtk requires the user to run
an X server under OS X and doesn't provide native look or feel.  For
OS X there's Qt, XUL, wxwidgets, tk, and probably some others I'm not
including.

>  3. (Jon option) write a pure GUI from scratch, in pure OCaml. A
> project similar to Qt or WxWidgets for C++. It seems doable to have a
> basic GUI but handling all i18n and desktop interoperability issues
> seems pretty complicated;

I'm starting to think this is the most promising direction.  Build it
on top of a cross-platform graphics toolkit like Cairo or SDL, then
handle all the logic in ocaml.  It gives developers a single target to
write for at the expense of (probably) never getting native look and
feel.

> Personnally, I don't know what decision to take. My current GUI code
> is in Lablgtk2 but, as stated in other emails, use of Gtk2 is too
> difficult for me. And I don't want to go into another reinvent the
> wheel syndrom. (sigh)

Alas, the cross-language cross-platform gui toolkit with native
look-and-feel is a wheel that has yet to be invented.

-- 
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->

Re: [Caml-list] Does LablTk have a future?

[Matt Gushee]

David Thomas wrote:

>>Yes but we gain the ability to have a better
>>interface on all platforms.
> 
> While pleasantly egotistical, I would have to say that
> this is a false statement.  Yes, there are problems
> with any given windowing system.  Note, however, that
> the user has already chosen the system whose
> shortcomings they feel the most comfortable with.  

True in a way. But really, the vast majority of end users have not 
chosen. Their employer, school, or computer vendor has chosen Windows 
for them, and they become used to Windows and never give anything else a 
fair trial.

But the end result is the same, I suppose.

--
Matt Gushee
Englewood, CO, USA

Re: [Caml-list] Does LablTk have a future?

[Matt Gushee]

Jon Harrop wrote:

>>Specific in what sense? And do you mean LablTk as a tool, or as a book
>>topic?

> I meant that the topic "GUI programming using lablTK" is too specific for a 
> book.

Okay, I thought that was probably what you meant. And you're probably right.

>>Ever used the Canvas or Text widgets? There's a lot going on there.
> 
> I'm using the Text widget in a very simple way. I may have to start using the 
> canvas widget because I can't figure out how to do various things (e.g. a 
> spreadsheet).

Yes, using Text for a spreadsheet is pushing the envelope quite a bit. 
It's certainly possible with Canvas. The other option would be to have a 
bunch of Text or Entry widgets laid out with the Grid geometry manager.

> Yes. As OCaml gains popularity it will be commercially viable to publish 
> cheaper books. In the mean time, if you're interested in making money, 
> perhaps educational software would be better?

Okay, you've got my attention. I've had vague thoughts in that direction 
myself, and it happens that I taught English as a Second Language for a 
few years before getting into geekery. What thoughts do you have about 
the opportunities in that field?

> Incidentally, OpenGL is extremely important for us. So a GUI toolkit must be 
> able to handle OpenGL widgets. Indeed, this begs the question: why not do the 
> whole thing in OpenGL?

It might be a good idea. My starting point was enlightened 
self-interest: I know Tk and LablTk fairly well, and I perceive that 
LablTk needs some help if it is to remain (become?) useful. Whereas I'm 
almost totally ignorant of OpenGL. It's one of the many things I think I 
ought to learn, but haven't found time.

--
Matt Gushee
Englewood, CO, USA

Re: [Caml-list] Does LablTk have a future?

[Jon Harrop]

On Thursday 01 September 2005 05:17, Matt Gushee wrote:
> Jon Harrop wrote:
> > I meant that the topic "GUI programming using lablTK" is too specific for
> > a book.
>
> Okay, I thought that was probably what you meant. And you're probably
> right.

There may well be a market for a book on GUI programming in OCaml (including 
OpenGL).

I've managed to get my database app up and running with lablgtk but it 
required a lot of weirdness (e.g. lots of mutual recursion, a strange 
"memoizing" wrapper for window creation functions to let me hide and show 
windows by destroying and recreating them). Having a book on the subject 
could have saved me a lot of time. The problem is, does anyone know how such 
things should be written?

> Yes, using Text for a spreadsheet is pushing the envelope quite a bit.
> It's certainly possible with Canvas. The other option would be to have a
> bunch of Text or Entry widgets laid out with the Grid geometry manager.

I think GTK will let me do this without too much difficulty. The more I use it 
and the more hassle I have (most of yesterday was spent making fundamental 
changes to my implementation, e.g. to let me hide windows) the more I think 
it would be easier to just start from scratch using OpenGL.

> > Yes. As OCaml gains popularity it will be commercially viable to publish
> > cheaper books. In the mean time, if you're interested in making money,
> > perhaps educational software would be better?
>
> Okay, you've got my attention. I've had vague thoughts in that direction
> myself, and it happens that I taught English as a Second Language for a
> few years before getting into geekery. What thoughts do you have about
> the opportunities in that field?

Vast. Educational software can be cheap because there are no overheads for 
making and shipping the product. Dispatch is O(1) for the human (you don't 
have to do anything per order, it is all automated). So it has the moral 
benefit of letting you help a lot more people whilst also being economically 
viable.

I'm aiming Presenta at the metamarket above this. Ultimately, I hope Presenta 
will let users write technical slideshow presentations that they can then 
sell. It will include an embedded (typeset!) OCaml-like DSL that allows users 
to create and manipulate vector graphics that will be rendered via OpenGL 
using Smoke, as well as a "manual" vector graphics editor (e.g. like a 
cut-down version of Corel DRAW).

As Presenta is written entirely in OCaml, I may even try to support dynamic 
loading of code. However, the core (e.g. the renderer) is performance 
critical and needs to be compiled to native code to achieve good performance.

> > Incidentally, OpenGL is extremely important for us. So a GUI toolkit must
> > be able to handle OpenGL widgets. Indeed, this begs the question: why not
> > do the whole thing in OpenGL?
>
> It might be a good idea. My starting point was enlightened
> self-interest: I know Tk and LablTk fairly well, and I perceive that
> LablTk needs some help if it is to remain (become?) useful. Whereas I'm
> almost totally ignorant of OpenGL. It's one of the many things I think I
> ought to learn, but haven't found time.

Have you seen all of the demos on our site?

  http://www.ffconsultancy.com/products/ocaml_for_scientists/visualisation
  http://www.ffconsultancy.com/free/maze
  http://www.ffconsultancy.com/free/ray_tracer
  http://www.ffconsultancy.com/free/ray_tracer/comparison.html

Also, my book has a chapter describing the basics of OpenGL and its use via 
LablGL.

I've already done a lot of work on OpenGL-based GUIs written in OCaml, of 
course, and I'm willing to help create a decent toolkit. I think we should 
start with a scene graph and picking. I am particularly interested in peer 
review of my scene graph design. Perhaps we could use polymorphic variants to 
make the scene graph extensible?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

GUI for OCaml (was: Re: [Caml-list] Does LablTk have a future?)

[David MENTRE]

Hello,

2005/8/30, Jon Harrop <jon@ffconsultancy.com>:
>  I had tried lablgtk before but failed to get to grips with it. 

The client of my application is also written in Lablgtk2 and, despite
helpful answers by Jacques Garrigue and Olivier Andrieux as well as
SooHyoung Oh's tutorials, I find programming with Labgtk2 not very
easy (to say the least). I find Lablgtk2 is largely under-documented.
Of course, this is a large task that cannot be achieved by two
individuals.

> I think it would be more constructive to create a decent cross-platform GUI
> library from the ground up for FPLs/OCaml. This wouldn't need to be anything
> fancy, just easy access to the simplest GUI elements to start with. I'd like
> to see GUIs described by purely functional data structures. 

I'd also loved too. Having a cross-platform GUI (with native look and
behaviour on Windows and MacOS X),   programmed using a functional
style, well documented (with reference manual and tutorial) and with
necessary tools (GUI design application) would be very very helpful.

However this is a huge task. To add on your initial question:
  1. do you think a minimal part of the OCaml community could
aggregate to ensure the long term maintainability of the toolkit?

  2. how to have a modern look (with whatever definition you might
find for it) which *is* a discriminant point when choosing a GUI?

  3. how to respond to toolkit's users that need to have more "exotic"
widgets/systems?

Yours,
david

Re: GUI for OCaml

[Christophe Raffalli]

David MENTRE a écrit :

 > Hello,
 >
 > 2005/8/30, Jon Harrop <jon@ffconsultancy.com>:
 >
 >> I had tried lablgtk before but failed to get to grips with it.
 >
 >
 >
 > The client of my application is also written in Lablgtk2 and, despite
 > helpful answers by Jacques Garrigue and Olivier Andrieux as well as
 > SooHyoung Oh's tutorials, I find programming with Labgtk2 not very
 > easy (to say the least). I find Lablgtk2 is largely under-documented.
 > Of course, this is a large task that cannot be achieved by two
 > individuals.
 >
 >
 >> I think it would be more constructive to create a decent 
cross-platform GUI
 >> library from the ground up for FPLs/OCaml. This wouldn't need to be 
anything
 >> fancy, just easy access to the simplest GUI elements to start with. 
I'd like
 >> to see GUIs described by purely functional data structures.
 >
 >
 >
 > I'd also loved too. Having a cross-platform GUI (with native look and
 > behaviour on Windows and MacOS X),   programmed using a functional
 > style, well documented (with reference manual and tutorial) and with
 > necessary tools (GUI design application) would be very very helpful.
 >

I would prefer a GUI programming language (similar to TeX for word 
processing). This might be easier to develop, can either be static (the 
widget build at compile time) or dynamic, and most of all, it is easier 
to modify an existing GUI.

 > However this is a huge task. To add on your initial question:
 >   1. do you think a minimal part of the OCaml community could
 > aggregate to ensure the long term maintainability of the toolkit?
 >

 >   2. how to have a modern look (with whatever definition you might
 > find for

  it) which *is* a discriminant point when choosing a GUI?

 >

Why a modern look, you should have the look of the OS you are running on,
using the OS X look on OS X,
the windows look on windows,
the KDE (with the user skin) look on KDE etc ...

This is were things are difficult and where a programming language to 
design the GUI is needed, because the GUI elements do not have the same 
dimension on all platform.

 >   3. how to respond to toolkit's users that need to have more "exotic"
 > widgets/systems?
 >

Let's start with simple thing for a basic toolkit,

Then, if the librairy is powerfull enough, it should be possible to 
design new widget entierely in OCaml with the library ?


 > Yours,
 > david
 >
 > _______________________________________________
 > Caml-list mailing list. Subscription management:
 > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
 > Archives: http://caml.inria.fr
 > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
 > Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Re: GUI for OCaml

[David MENTRE]

Hello Christophe,

2005/8/30, Christophe Raffalli <christophe.raffalli@univ-savoie.fr>:
> I would prefer a GUI programming language (similar to TeX for word
> processing). This might be easier to develop, can either be static (the
> widget build at compile time) or dynamic, and most of all, it is easier
> to modify an existing GUI.

I'm not fond of yet another Domain Specific Language (DSL), except if
it brings clear advantages (of which I'm not yet convinced).

I don't mind learning a DSL from time to time, but not each time I
need to program a part of my application.

For example, in my current code, I'm using CDuce's DSL and WDialog's
DSL. As an engineer, I would not be very happy to be forced to use yet
another DSL. And other developers in my project need to agree with
this complexity.

BTW, some research has been done one using functional style to program
GUI (in Haskell??). We should at least have a look on it.


> Why a modern look, you should have the look of the OS you are running on,
> using the OS X look on OS X,
> the windows look on windows,
> the KDE (with the user skin) look on KDE etc ...

Your right. I was referring to labltk vs. lablgtk1 vs. lablgtk2. This
is a sub-issue of the general issue of having a native look and
behaviour on all platforms.

> This is were things are difficult and where a programming language to
> design the GUI is needed, because the GUI elements do not have the same
> dimension on all platform.

I don't see why a language rather than a library can improve this point.

> Let's start with simple thing for a basic toolkit,

Agree.

> Then, if the librairy is powerfull enough, it should be possible to
> design new widget entierely in OCaml with the library ?

It could be nice. But as an engineer, I'm always wondering: how can I
reuse that code developed and debugged by others. Reinventing the
wheel is sometimes good, but not always.

Yours,
david

Re: [Caml-list] Re: GUI for OCaml

[Bünzli Daniel]

Le 30 août 05 à 12:28, David MENTRE a écrit :

> BTW, some research has been done one using functional style to program
> GUI (in Haskell??). We should at least have a look on it.

Some references are

 > fruit [1], based on functional reactive programming.
 > fudgets [2], based on lazy streams.

For multiplatform developpement, an approach would be to have a  
conceptual model of user inter-face/action, i.e. no look, just feel.  
This model could then be interpreted (possibly with hints to adjust  
the look) with the tools provided by the different platform specific  
toolkits. A kind of front-end/back-end architecture. Easy to say...

Daniel

[1]
<http://www.haskell.org/fruit/>

[2]
<http://www.cs.chalmers.se/ComputingScience/Research/Functional/ 
Fudgets/>
<http://www.cs.chalmers.se/~hallgren/Thesis/top.html>

Re: [Caml-list] Re: GUI for OCaml

[David Thomas]

--- David MENTRE <david.mentre@gmail.com> wrote:

> > I would prefer a GUI programming language (similar
> > to TeX for word processing). This might be easier 
> > to develop, can either be static (the widget build

> > at compile time) or dynamic, and most of all, it
is
> > easier to modify an existing GUI.
> 
> I'm not fond of yet another Domain Specific Language
> (DSL), except if it brings clear advantages (of
which
> I'm not yet convinced).

I quite like the notion of a DSL for GUIs, presuming
that it (1) makes simple things simple, with
reasonable defaults for each platform and few if any
unpleasant surprises; (2) keeps complicated things
possible - we shouldn't be sacrificing flexibility;
and (3) is reasonably orthogonal - if the code looks
similar, the layout produced should look similar, with
only those changes in the gui actually reflected by
changes in the code.

One additional advantage this has is that it allows
GUI work to be done by the people who are good at
designing GUI's, rather than those that know the
particular system being worked with, without producing
a lot of icky code. 

> BTW, some research has been done one using
functional
> style to program GUI (in Haskell??). We should at 
> least have a look on it.

That's a good point.  I've spent way too long looking
at OO examples of GUIs.  What does a functional GUI
framework look like?


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

Re: [Caml-list] Re: GUI for OCaml

[Mark Shinwell]

On Tue, Aug 30, 2005 at 11:53:54AM +0200, Christophe Raffalli wrote:
> Why a modern look, you should have the look of the OS you are running
> on, using the OS X look on OS X, the windows look on windows, the KDE
> (with the user skin) look on KDE etc ...

Personally I'd love to see an up-to-date interface to wxWindows, which
provides all of the above, but from what I hear on the grapevine
previous attempts at such a layer have been frought with difficulties.

Mark

Re: [Caml-list] Re: GUI for OCaml

[Jacques Carette]

Christophe Raffalli wrote:

> I would prefer a GUI programming language (similar to TeX for word 
> processing). This might be easier to develop, can either be static 
> (the widget build at compile time) or dynamic, and most of all, it is 
> easier to modify an existing GUI.
>
What about re-using the work from Mozilla - I mean Gecko and XUL.  See 
the links on http://www.mozilla.org/projects/.  It should be relatively 
simple to create a human-friendly syntax for it, so I don't think that 
XML is a real issue.

Jacques

Re: [Caml-list] Re: GUI for OCaml

[Pietro Abate]

On Tue, Aug 30, 2005 at 10:22:56AM -0400, Jacques Carette wrote:
> What about re-using the work from Mozilla - I mean Gecko and XUL.  See 
> the links on http://www.mozilla.org/projects/.  It should be relatively 
> simple to create a human-friendly syntax for it, so I don't think that 
> XML is a real issue.

Using XUL with ocaml would be great... they are working on building
everything (firefox, thunderbird and friends) on the top of xmlrunner,
that is a multi platform library to display xul widgets. The big problem
is that at the moment you can write 'actions' (DCOM objects ??) only in
javascript and c++, and there is a project to implement a python
backend. javascript and c++ are a pain to use. the python backend is
still in a preliminary stage of development (I think). It would be
fantastic to have ocaml bindings (don't look at me :) )... 

Hand writing gui, in my opinion, is something of the past. Using, for
example glade + code generator or XUL is the way to go.

:)
p

-- 
++ Blog: http://blog.rsise.anu.edu.au/?q=pietro
++ 
++ "All great truths begin as blasphemies." -George Bernard Shaw
++ Please avoid sending me Word or PowerPoint attachments.
   See http://www.fsf.org/philosophy/no-word-attachments.html

Re: GUI for OCaml (was: Re: [Caml-list] Does LablTk have a future?)

[Richard Jones]

On Tue, Aug 30, 2005 at 09:16:20AM +0200, David MENTRE wrote:
> The client of my application is also written in Lablgtk2 and, despite
> helpful answers by Jacques Garrigue and Olivier Andrieux as well as
> SooHyoung Oh's tutorials, I find programming with Labgtk2 not very
> easy (to say the least). I find Lablgtk2 is largely under-documented.
> Of course, this is a large task that cannot be achieved by two
> individuals.

Lablgtk2 is a pain, but I think the pain comes from Gtk itself, not
any shortcomings in lablgtk2 or ocaml.

> I'd also loved too. Having a cross-platform GUI (with native look and
> behaviour on Windows and MacOS X),   programmed using a functional
> style, well documented (with reference manual and tutorial) and with
> necessary tools (GUI design application) would be very very helpful.
> 
> However this is a huge task. [...]

It is a huge task.  I'm not even sure what a "functional" API for a
GUI toolkit would look like.  Ideas?  Example code snippets?

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: GUI for OCaml (was: Re: [Caml-list] Does LablTk have a future?)

[mmzeeman]

> It is a huge task.  I'm not even sure what a "functional" API for a
> GUI toolkit would look like.  Ideas?  Example code snippets?
>

The Clean programming language seems to have a nice functional GUI api
(http://www.cs.ru.nl/~clean/index.html).

Personnaly I like the Qt api. I think it should be possible to
create/generate c++ to ocaml-objects wrappers so you could create Qt GUIs
with ocaml.

Regards,

Maas

Re: GUI for OCaml (was: Re: [Caml-list] Does LablTk have a future?)

[Jon Harrop]

On Tuesday 30 August 2005 16:33, mmzeeman wrote:
> The Clean programming language seems to have a nice functional GUI api
> (http://www.cs.ru.nl/~clean/index.html).

Thanks for the link. I'll check it out.

> Personnaly I like the Qt api. I think it should be possible to
> create/generate c++ to ocaml-objects wrappers so you could create Qt GUIs
> with ocaml.

This is exactly the kind of thing that I'd like to avoid. Firstly, Qt is a 
very expensive commercial product so we wouldn't use it. Secondly, Qt goes to 
great lengths to circumvent flaws in the C++ language. It would be a great 
shame to "port" these to OCaml. Finally, I found that TrollTech's own Qt 
demos segfault reliably, so I'd question Qt's stability.

I'd much rather see only low-level bindings with all of the widget code 
written in OCaml.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: GUI for OCaml (was: Re: [Caml-list] Does LablTk have a future?)

[yoann padioleau]

On 30 août 05, at 17:33, mmzeeman wrote:

>
>
>
>> It is a huge task.  I'm not even sure what a "functional" API for a
>> GUI toolkit would look like.  Ideas?  Example code snippets?
>>
>>
>
> The Clean programming language seems to have a nice functional GUI api
> (http://www.cs.ru.nl/~clean/index.html).
>
> Personnaly I like the Qt api. I think it should be possible to

Is there really big a differences between Qt, Gtk, Wxwindows, ... ?
The only difference is maybe the number of widgets it supports, but  
all those API share the same kind of style,
the same basic widgets.

> create/generate c++ to ocaml-objects wrappers so you could create  
> Qt GUIs
> with ocaml.
>
> Regards,
>
> Maas
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

Re: GUI for OCaml (was: Re: [Caml-list] Does LablTk have a future?)

[Matt Gushee]

yoann padioleau wrote:

 > Is there really big a differences between Qt, Gtk, Wxwindows, ... ?
 > The only difference is maybe the number of widgets it supports, but 
all those API share the same kind of style,
 > the same basic widgets.


No, there are also important differences in their event handling 
mechanisms ... can't really go into detail at this moment, but it's 
something that needs to be considered.

-- 
Matt Gushee
Englewood, CO, USA

Re: GUI for OCaml (was: Re: [Caml-list] Does LablTk have a future?)

[Jon Harrop]

On Tuesday 30 August 2005 15:14, Richard Jones wrote:
> Lablgtk2 is a pain, but I think the pain comes from Gtk itself, not
> any shortcomings in lablgtk2 or ocaml.

Yes. My understanding is that lablgtk does a lot to hide the hideousness 
beneath.

> > However this is a huge task. [...]
>
> It is a huge task.

Depending on what exactly we're talking about, I think it is entirely 
tractable for one person, let alone a team.

> I'm not even sure what a "functional" API for a 
> GUI toolkit would look like.  Ideas?  Example code snippets?

I think the GUI code should be split into definition (i.e. how the widgets are 
laid out) and execution (i.e. what functions are called for GUI events). The 
former should be functional in style because it is easier to write and more 
succinct and the latter should be imperative in style because it is 
essentially poking a state machine about.

The functional definition could be a data structure that is folded over to 
accumulate the widgets needed by the subsequent event code. For example, 
consider a searchable list with a labelled search box, a scrollable list and 
a button to add new entries (off the top of my head):

let gui =
  `Frame [`Frame [`Label "Search: "; `Entry];
          `List;
          `Button "Add"];;

let rec make parent accu = function
  | `Frame l -> List.fold_left (make (Frame.create `Top parent)) accu l
  | `Label text ->
      let widget = Label.create ~text parent in
      pack [widget];
      `Label widget :: accu
  | `Entry ->
      let widget = Entry.create parent in
      pack [widget];
      `Entry widget :: accu
  | `List ->
      let parent = build_frame side fill expand parent in
      let list = Listbox.create ~width parent in
      pack ~side:`Left ~fill:`Both ~expand:true [list];
      let scroll_bar = Scrollbar.create parent in
      Listbox.configure ~yscrollcommand:(Scrollbar.set scroll_bar) list;
      Scrollbar.configure ~command:(Listbox.yview list) scroll_bar;
      pack ~side:`Right ~fill:`Y [scroll_bar];
      `List list :: accu
  | `Button text ->
      let widget = Button.create ~text parent in
      pack [widget];
      `Button widget :: accu

let [_; `Entry search; `List list; `Button add] = make top [] gui;;

You'd want to add a call to "pack" after each call to "*.create" and you'd 
want to have HBox and VBox instead of Frame but the basic idea is there. I 
can't see a good way to statically type such code in general so I've left it 
with an incomplete pattern match.

Perhaps we should start by writing such a wrapper that can target either 
labltk or lablgtk?

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: GUI for OCaml (was: Re: [Caml-list] Does LablTk have a future?)

[Chris Campbell]

First, I hate AJAX.  Breaks the back button! :(  Yes, this is the
second time I've written this email.

On 30/08/05, Jon Harrop <jon@ffconsultancy.com> wrote:
> On Tuesday 30 August 2005 15:14, Richard Jones wrote:
> > Lablgtk2 is a pain, but I think the pain comes from Gtk itself, not
> > any shortcomings in lablgtk2 or ocaml.
> 
> Yes. My understanding is that lablgtk does a lot to hide the hideousness
> beneath.
> 
> > > However this is a huge task. [...]
> >
> > It is a huge task.
> 
> Depending on what exactly we're talking about, I think it is entirely
> tractable for one person, let alone a team.
> 
> > I'm not even sure what a "functional" API for a
> > GUI toolkit would look like.  Ideas?  Example code snippets?
> 
> I think the GUI code should be split into definition (i.e. how the widgets are
> laid out) and execution (i.e. what functions are called for GUI events). The
> former should be functional in style because it is easier to write and more
> succinct and the latter should be imperative in style because it is
> essentially poking a state machine about.
 
This sounds like QTk.  It is a wrapper to Tk that uses records (tuples
and atoms are records in Oz) and call backs to implement the gui. 
It's quite effective.  In Oz, your example would look something like
this... (warning, last Oz use was a while ago)

Qtk.build td(lr(label:"Search" text(handle: H))
                 (lr(button(text:"Add" action:P)

Where P and H are call back procedures.

> Perhaps we should start by writing such a wrapper that can target either
> labltk or lablgtk?

Make it independant to a degree.  Most GUIs offer the same functionality anyway.


Chris

Re: GUI for OCaml (was: Re: [Caml-list] Does LablTk have a future?)

[yoann padioleau]

>>
>>> I'm not even sure what a "functional" API for a
>>> GUI toolkit would look like.  Ideas?  Example code snippets?
>>>

In fact the API is already "functional" in some way, because in ocaml
(as well as in perl, ruby, ...) you can pass closure as callbacks.  
This is something really great for GUI compared
to langage like C where you have to separate the code responsible for  
creation of the widget from
the code responsible for the action on the widget.

Another point is that it is functional because you can compose the  
widgets together. You can nest them so the nesting of the code
can be put in paralell with the nesting in the widgets.

You can do

build_app_widget(title: "myapp",
      (build_vbox
        (build_menu
           (build_item "File" callback:(fun () -> some_action))
           (build_item "Close"  callback:(fun () -> some_other_action)
      ...
     )
     (build_hbox
       (build_canvas
         (...
      )
   ...
  )



>>
>> I think the GUI code should be split into definition (i.e. how the  
>> widgets are
>> laid out) and execution (i.e. what functions are called for GUI  
>> events). The
>> former should be functional in style because it is easier to write  
>> and more
>> succinct and the latter should be imperative in style because it is
>> essentially poking a state machine about.
>>
>
> This sounds like QTk.  It is a wrapper to Tk that uses records (tuples
> and atoms are records in Oz) and call backs to implement the gui.
> It's quite effective.  In Oz, your example would look something like
> this... (warning, last Oz use was a while ago)
>
> Qtk.build td(lr(label:"Search" text(handle: H))
>                  (lr(button(text:"Add" action:P)
>
> Where P and H are call back procedures.
>

 From what I remember you can do exactly the kind of stuff you wrote  
with lablgtk quite easily.

The only problem is that many times in H and P you want to modify the  
state of the widget (for instance modify the text in an entry) and in  
that
case you have to name the widget  with a let.


>
> Make it independant to a degree.  Most GUIs offer the same  
> functionality anyway.
>


I agree.

>
> Chris
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

Re: GUI for OCaml (was: Re: [Caml-list] Does LablTk have a future?)

[Chris Campbell]

On 30/08/05, Richard Jones <rich@annexia.org> wrote:
> On Tue, Aug 30, 2005 at 09:16:20AM +0200, David MENTRE wrote:
> > The client of my application is also written in Lablgtk2 and, despite
> > helpful answers by Jacques Garrigue and Olivier Andrieux as well as
> > SooHyoung Oh's tutorials, I find programming with Labgtk2 not very
> > easy (to say the least). I find Lablgtk2 is largely under-documented.
> > Of course, this is a large task that cannot be achieved by two
> > individuals.
> 
> Lablgtk2 is a pain, but I think the pain comes from Gtk itself, not
> any shortcomings in lablgtk2 or ocaml.

Yep.  Every time I've used a binding to Gtk in any language it's been
pretty ugly.  Unfortunately it's seems to be the only one any wants to
bind to on Linux. :'(

>> I'd also loved too. Having a cross-platform GUI (with native look and
>> behaviour on Windows and MacOS X),   programmed using a functional
>> style, well documented (with reference manual and tutorial) and with
>> necessary tools (GUI design application) would be very very helpful.
>>
>> However this is a huge task. [...]
> 
> It is a huge task.  I'm not even sure what a "functional" API for a
> GUI toolkit would look like.  Ideas?  Example code snippets?

Ch 10 or 11 of CTM (Concepts, Techniques and Models of Computer
Programming by Haridi and Van Roy) describes a good model and the
trade offs of various models.  The ref documentation for QTk, the
toolkit they describe, is available at
http://www.mozart-oz.org/documentation/mozart-stdlib/wp/qtk/html/index.html.

It's incredibly simple, yet very powerful.

Re: GUI for OCaml (was: Re: [Caml-list] Does LablTk have a future?)

[yoann padioleau]

On 30 août 05, at 09:16, David MENTRE wrote:

> Hello,
>
> 2005/8/30, Jon Harrop <jon@ffconsultancy.com>:
>
>>  I had tried lablgtk before but failed to get to grips with it.
>>
>
> The client of my application is also written in Lablgtk2 and, despite
> helpful answers by Jacques Garrigue and Olivier Andrieux as well as
> SooHyoung Oh's tutorials, I find programming with Labgtk2 not very
> easy (to say the least). I find Lablgtk2 is largely under-documented.

It seems to me that there is nothing original in the ocaml binding of  
gtk
so most of the time you can search in the documentation of gtk in any  
other langage
and "quite easily" adapt it to ocaml. Maybe the only problem with  
lablgtk is that it uses
the object facilities of ocaml and that many people are not very  
aware of those features. But in that case
what we need is a better documentation of the object features of ocaml.

> Of course, this is a large task that cannot be achieved by two
> individuals.

And I think it is not a good idea. We have to factor code and  
documentation.
It is better to have one good documentation of gtk in one langage,  
that 10 bad documentation
of gtk in 10 langages.
Maybe one day when .net or a similar thing will take over the world  
we will have less problems.

>
>
>> I think it would be more constructive to create a decent cross- 
>> platform GUI

Well, gtk is cross-platform.

>> library from the ground up for FPLs/OCaml.

And yet again reinvent the wheel. I am quite sure that you will  
reinvent just exactly gtk :)


>> This wouldn't need to be anything
>> fancy, just easy access to the simplest GUI elements to start with.

Well you have already that with lablgtk.

>> I'd like
>> to see GUIs described by purely functional data structures.

I had a look to fruit in haskell, fudgets, fran, ... and other  
attempts to make gui in functionnal style, and most of the time
I found the code more complex that the classical  widget/callback   
with global variable or closure model.


>>
>
> I'd also loved too. Having a cross-platform GUI (with native look and
> behaviour on Windows and MacOS X),   programmed using a functional
> style,


> well documented (with reference manual and tutorial) and with
>
You have that for gtk, ok it is not in ocaml but you can make the  
translation quite easily from langage X to ocaml.

> necessary tools (GUI design application) would be very very helpful.

Do you really find useful such RAD tools ?

About Lablgtk2 (was: e: GUI for OCaml)

[David MENTRE]

Hello Yoann,

2005/8/31, yoann padioleau <padator@wanadoo.fr>:
> > [me:]
> > well documented (with reference manual and tutorial) and with
> >
> You have that for gtk, ok it is not in ocaml but you can make the
> translation quite easily from langage X to ocaml.

Ok, let's me try to reword my criticism: I find the use of Labgtk2
objects not easy at all. I find the use of objects and the class
hierarchy very confusing. Maybe this is just an issue of documenting
the general mapping of Gtk2 signals, objects, ... to OCaml modules and
objects. Maybe ocamldoc should be improved to allow unfolding a method
accessible through the class hierarchy in one class. Or maybe I'm too
stupid to understand the toolkit. Or maybe I'm unable to grasp OCaml
objects. The net result is that using Lablgtk2 is really a pain.

However, I do use Labgtk2 for the graphical interface of my
application so I at least consider that I have written enough code to
make my own point of view. With all the examples, I'm able to write
basic interface (i.e. buttons, menus, etc.) through copy/paste. But
I'm still not able to write code that would match GUI design I would
like to have.

> > necessary tools (GUI design application) would be very very helpful.
> 
> Do you really find useful such RAD tools ?

Yes. Yes and yes. Have you ever programmed a GTk2 application? Have
you ever see the number of options available for each widget?

I'm using Glade to produce the XML interface for Labgtk2 (of course,
callbacks are written in regular OCaml code). It saved me hours of
interface layout design. I'm not speaking of two buttons into a
window. I'm speaking of sliding panes, with several buttons, text
boxes and TreeView in each, playing with options to make relative
positioning suits your needs.

Yours,
d.

Re: About Lablgtk2 (was: e: GUI for OCaml)

[yoann padioleau]

>

David mentre wrote:

> Ok, let's me try to reword my criticism: I find the use of Labgtk2
> objects not easy at all. I find the use of objects and the class
> hierarchy very confusing. Maybe this is just an issue of documenting
> the general mapping of Gtk2 signals, objects, ... to OCaml modules and
> objects. Maybe ocamldoc should be improved to allow unfolding a method
> accessible through the class hierarchy in one class.

Yes, that is a good idea. Some tools offer such a thing, for instance
in Eiffel there is a command "short"  and a command "long"   that
generate documentation from a class,  the first one with only the new  
method, and second
one with all the methods unfolded.


> Or maybe I'm too
> stupid to understand the toolkit. Or maybe I'm unable to grasp OCaml
> objects. The net result is that using Lablgtk2 is really a pain.
>
> However, I do use Labgtk2 for the graphical interface of my
> application so I at least consider that I have written enough code to
> make my own point of view. With all the examples, I'm able to write
> basic interface (i.e. buttons, menus, etc.) through copy/paste.


> But
> I'm still not able to write code that would match GUI design I would
> like to have.

Ok, that is certainly the reason
why we dont have the same feeling about lablgtk,
we must certainly not have the same standard of quality.
I am quite satisfied with someting rudimentary.

>
>
>>> necessary tools (GUI design application) would be very very helpful.
>>>
>>
>> Do you really find useful such RAD tools ?
>>
>
> Yes. Yes and yes. Have you ever programmed a GTk2 application?

Yes, yes, and yes :) (well it was gtk).
A few years ago I programmed one in C++ (I was forced by my school)   
so from this first experience I learned
the toolkit, so maybe this experience was helpful when doing my  
second app with lablgtk
(which was really easier than in c++).


> Have
> you ever see the number of options available for each widget?

No. Well I dont use them most of the time, the optional arguments
and keyword argumentss of olabl (now ocaml3)) is really a big help  
in  that respect.
You dont have to know all the options.


>
> I'm using Glade to produce the XML interface for Labgtk2 (of course,
> callbacks are written in regular OCaml code). It saved me hours of
> interface layout design. I'm not speaking of two buttons into a
> window. I'm speaking of sliding panes, with several buttons, text
> boxes and TreeView in each,

I must admit that my application was not very advanced, but it had  
many different kind of widgets
(buttons, text, boxes, pane, scrollist, menubar, labels, ...)
Here is a screenshot:
   http://lfs.irisa.fr/~pad/LFSWEB/(ext:gif)|(ext:jpg)|(ext:png)/ 
name:lfs-itunes-screenshot0/
Just a light clone of iTunes, the music application of Apple.


> playing with options to make relative
> positioning suits your needs.

The problem from what I remember is that glade fix position, it fix  
the size of your application,
I prefer not to state any fixed position and let the user adjust the  
panes, scrollbar width, ...
In my program I only state constraints (it must be right justified,  
it must be abobe that, ...).
The reason is that I had previously been frustrated by application  
that you can run only in 1024x768, a
applications where you cannot adjust the side of a subwindow, ...

>
> Yours,
> d.
>
>

Re: [Caml-list] Does LablTk have a future?

[Olivier Andrieu]

 Jon Harrop [Monday 29 August 2005] :
 > May I add another question to this thread: What do people think of
 > OCaml's GUI libraries in terms of stability?

Well there are not that many libraries for GUIs in ocaml. We have :

 - LablTk/CamlTk
 - LablGTK
 - Wxcaml [1]
 - OCaml-Win32 [2]

Are there any others ?

[1] http://pllab.kaist.ac.kr/~shoh/ocaml/wxcaml/doc/
[2] http://www.speakeasy.org/~hchomsky/ocaml-win32.html

-- 
   Olivier