Re: [Caml-list] Re: ocamlbrowser [was labels]

[John Max Skaller <skaller@ozemail.com.au>]

"Benjamin C. Pierce" wrote:
 
> Here's one possible design (I'm sure it can be improved).
>    * Every navigation command comes in three forms:
>        1) open a *new* window for the new information
>        2) re-use *this* window to display the new information
>    * Style (1) is the default.  Pressing SHIFT while clicking gets you
>      style (2).

	No. Left button is 'same window'. Right button is popup menu.
It is the standard used in MS-Windows (eg in Windows Explorer).
Using this technique means only ONE mouse click for both cases,
in the second case the default is 'new' window, and requires no
mouse movement. Other options require movement. Neither option
requires any keyboard.

	Holding mouse still over active element pops up tooltip help
with extra information.

>    * A netscape-style "back" command can be used to restore the contents
>      of the current (or temp) window to its previous state, 

	Yes.

>  or to close a window that you just created.

	No: examine your browser. Back does nothing at the root.

>    * Perhaps there chould be some way to make the SHIFT and CONTROL
>      modifiers sticky.

	Modifiers should be avoided at all costs. They should only
be used for 'expert', 'dangerous' and 'user defined' functions. More
generally,
navigation should be possible with the mouse alone. The keyboard should
provide alternatives, but only be required for data entry and dangerous
functions. For example, by default 'search' should use the word the
cursor is on in an edit file and NOT require typing anything.
If an entry box is use, the default should support history by a drop
down list, 
again allowing no-keyboard operation in many cases. Again, see browsers.
 
> A possible refinement:
>    * One window on the screen is designated the "temp window" (initially,
>      there is no temp window; one is created the first time it is needed,
>      and the same window is used thereafter).
>    * Add a navigation style:
>        3) use the *temp* window
>    * Pressing CONTROL when clicking gets you style (3).
> (I'm not sure whether this refinement is worth the trouble -- just having
> mode (1) plus a "back" keystroke to close the new window when done might
> be enough.)

	No. This kind of refinement is definitely worth the trouble.

********************************************************************
  
	Here is a general comment. It is a serious bug of all current
GUI design that to make a functional GUI, one must take the basic
functionality like Ocamlbrowser today, and add more and more features
to control layout/style -- which have nothing at all to do with the
underlying functionality.

	A system for managing this complex problem independently
of the application is needed. Such systems exist, they're called
window managers on X systems, and they're quite archaic and
close to useless.

	I have designed and implemented an approach to a partial
solution (lots of qualifiers here!). It is called HWM, or
Heirarchical Window Manager. HWM uses a tree widget to represent
'containment' of application and sub-application level windows.

	Some of the windows used are containers: for example:
	a) multi-paned window (vertical, horizontal etc)
	b) notebook
	c) display

and some of the windows are application windows. These windows
are also containers by delegation to their parent.

	Using the tree widget, it is possible to move, iconise,
or destroy whole subtrees of windows. For example consider


	display
	  ocamlbrowser-toplevel
	    module data
	      symbol list
              text
	    module data
	      symbol list
	      text

Here, 'module data' is a horizontally paned window, display is your X
windows
display. Ocamlbrowser-toplevel is a single non-container window, so we
have three top level windows at this point. I HATE that! So I (and NOT
ocamlbrowser) simply create a notebook:


	display
	  mybook
	  ocamlbrowser-toplevel
	    module data
	      symbol list
              text
	    module data
	      symbol list
	      text

and then move the two module panes into it with drag and drop:


	display
	  mybook
	    module data
	      symbol list
              text
	    module data
	      symbol list
	      text
	  ocamlbrowser-toplevel

and now there are only two top level windows. Now, I want to see
both module data at the same time. So I right click on the 'mybook'
entry and select 'metamorphise/vertical paned window' and the notebook
is changed into a vertical paned window. I want to edit the text
of one module, so I just drag it out to 'display' to change it
to a top level window. Indeed, I have TWO displays, and at the flick
of a mouse, I can move the display to the second screen.

I designed HWM because I had a system much more complex than Ocaml
to browse: the complete text and code for a literate programmed
book. I needed the system to manage multiple ways of organising
information, which required a lot of kinds of 'summary' windows
at different levels of modularity.

So I have an interesting suggestion here. Instead of enhancing
Ocamlbrowser, REMOVE most of the window management (there isn't
much anyhow), and replace it with calls to a new HWM API.

Then build HWM. This will give the USER extensive control over layout
and window management, and that system will work for ANY compliant
application (not just Ocamlbrowser).

I have implemented HWM in iTCL and in Python, both using Tcl/Tk with Tix
for the GUI. (Tix is mandatory for the tree widget, which Tk lacks).
Tk has some problems reparenting a window to another display.
Ocaml has some problems with dynamic loading (required so HWM
can manage independent applications).

An Ocaml based  HWM implementation would be an interesting use of
classes. At the most abstract level, one writes only a management
system for a tree data structure. Subclasses are used to add
the tree widget modelling. Further subclassing is used to add
actual containers. Dynamic loading is used to add a menu of
applications.

HWM runs first, and can be used to create new containers and
launch user applications. The current design handles 
'add child to parent' but does not provide any control over ordering.
However, it is possible to change the state of the containment
tree by manipulating the other windows (and tricky to get the
synchronisation right). It is also possible to reorganise the tree
under program control (just by manipulating the abstract tree,
everything else works by method polymorphism).

Is anyone interested? Can a Tix binding be created easily?

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