From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA01364; Mon, 9 Apr 2001 17:13:19 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA01359 for caml-list@pauillac.inria.fr; Mon, 9 Apr 2001 17:13:18 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id GAA18281 for ; Mon, 9 Apr 2001 06:43:56 +0200 (MET DST) Received: from localhost.localdomain (ppp41.dyn147.pacific.net.au [210.23.147.41]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f394hqf06294 for ; Mon, 9 Apr 2001 06:43:53 +0200 (MET DST) Received: from ozemail.com.au (IDENT:root@localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.8.7) with ESMTP id OAA01057; Mon, 9 Apr 2001 14:43:26 +1000 Message-ID: <3AD13DEE.6123BEBA@ozemail.com.au> Date: Mon, 09 Apr 2001 14:43:26 +1000 From: John Max Skaller X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: bcpierce@cis.upenn.edu CC: Jacques Garrigue , caml-list@inria.fr Subject: Re: [Caml-list] Re: ocamlbrowser [was labels] References: <240.986159775@saul.cis.upenn.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk "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