Re: [Caml-list] Using HTML as a standard GUI for Ocaml

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

On Sat, Mar 31, 2001 at 11:31:43AM +0200, Mattias Waldau wrote:
> - Is the idea below good or bad?
> - I am looking for ideas how to implement the idea below.
> - Making some kind of JSP/ASP-package for Ocaml could be a solution,
> but code likes that gets very messy.
> - What has been done? Unpublished code?
> - Alternatives?
> 
> Using HTML for GUIs
> ===================

can be a good idea, depending on your use.
> 
> Today there exists two flavors of gui for Ocaml based on Tcl or GTK.
> Tcl is portable, and GTK is becoming portable.

Gtk is portable, it works at least on X, windows, the linux framebuffer device
(soon) and possibly some others.

> What about using HTML-interfaces
> instead of standard GUIs like Tcl and GTK?

Well, i think this may be a good idea (sun is doing this) if you need to run
your code remotely and for system configuration and administration.

But, ...

Most web browser are huge beast, running slowly and ressource hungry. Also i
think you can do less things with html than you can do with modern toolkits.

Also there is the question of bandwith.

> The architecture is
> that you start some kind of HTTP-based server and than you
> start the browser and go to a local adress like
> http://localhost:8989/start.html.

Sun is doing this for their system/wbe server administration, but then i guess
everyone using this has fast web connection and quick boxes wiht loads of
memory

> The advantages are
> - Portable

Sure, ...

But i think you don't envision to run it on a text based browser like lynx ?

> - Much nicer looking GUI's, it is easier to add pictures, fonts etc
>   to a HTML-gui, than to a Tcl/GTK-based

Erm, ...

i don't think much people will be of the same opinion as you.

It may be easier for simple tasks, but there is much less things you can do
with HTML.

Also i hope you don't try to do OpenGL stuff and other such, i don't think it
will work.

> - Many GUI-operations are easier to do in HTML than in a standard
>   GUI-tool, for example HTML-tables are easier to create the
>   listboxes with columns.

But you have less control wit them, as well as one the callbacks you can add
to them. Also i am not html specialist but from what i know, the event loop
handling is really slow on a browser + server thing than what you can do with
even the slow tcl/tk toolkit.

> - Easy to create server-based solutions out of client-applications.
>   Only need to handle state in a general and scalable way.

This has nothing to do with GUIs, ...

> - Smaller executables, for example including GTK statically into
>   Unison increases the size from 700Kb to 2400Kb on Windows.

But you need the 20Mb + of mozilla/whatever installed.

> - Easier to integrate with other applikations, since two
>   applications can merged on the HTML-page

mmm, ...

i don't know about this, but i think you will launch a cgi to generate the
html page. if you have 2 pages, you would need to launch 2 cgis and merge
them, or have one of them call 2 other and do the merging.

I think it trully depends on what you want to do. Please provide a more
detailed context, and we could discuss it in more details.

> The disadvantages are
> - slower

much slower, and ressource hungry, yes ...

> - difficult to set focus correctly if the whole page is updated
>   after each input (bugs i IE). This can be solved by being

And naturally, don't forget that IE is not the only browser around.

>   XML-based and talk XML from the browser to the server (which
>   only works on IE>=5 and Netscape 6).
Sure, and XML is the solution to all your problems ... :)))

I am not that convinced, but then i am no XML expert.

> - browser incompabilities. (for example HTC in IE makes event
>   very easy to handle, but incompatible with active sheet on Netscape,
>   which is buggy)

Just use Standard html and forget about all the private extensions of the ones
and the others.

All in all, i think using html as guis is a solution only for the most
specialized of case, where having it running remotely is a requirement, like
in the sun case, but mostly it is simply to cumbersome and ugly to be of any
help for more advanced GUIs. I would not do it.

That said, in the ocaml oreilly book, you will find a chapter on how to write
a web server in ocaml, and some stuff that could lead to some of the things
you may want to do, please read it.

Friendly,

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