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.