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

[skaller <skaller@users.sourceforge.net>]

[-- 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 --]