From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id E8B05BDDB for ; Sat, 3 Sep 2005 14:31:19 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j83CVJeu032761 for ; Sat, 3 Sep 2005 14:31:19 +0200 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 OAA22299 for ; Sat, 3 Sep 2005 14:31:18 +0200 (MET DST) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j83CVGUN002473 for ; Sat, 3 Sep 2005 14:31:17 +0200 Received: from rosella (ppp32-47.lns1.syd6.internode.on.net [59.167.32.47]) by smtp1.adl2.internode.on.net (8.12.9/8.12.6) with ESMTP id j83CUtqG030911; Sat, 3 Sep 2005 22:01:07 +0930 (CST) (envelope-from skaller@users.sourceforge.net) Subject: Re: [Caml-list] Re: Feeding the OCaml GUI troll From: skaller To: Damien Bobillot Cc: Ville-Pertti Keinonen , Matt Gushee , caml-list@inria.fr In-Reply-To: <1A0BFF96-D811-4173-933F-F7BB69668856@m4x.org> References: <20050830174757.99765.qmail@web30510.mail.mud.yahoo.com> <200508302001.58080.jon@ffconsultancy.com> <3d13dcfc05083101487092acd5@mail.gmail.com> <43168841.9000302@havenrock.com> <1125580528.7192.23.camel@localhost.localdomain> <1125646841.735.57.camel@acerf.exomi.com> <1125664781.7262.51.camel@localhost.localdomain> <1A0BFF96-D811-4173-933F-F7BB69668856@m4x.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7++EPM45+sxRrkfXbpGa" Date: Sat, 03 Sep 2005 22:30:55 +1000 Message-Id: <1125750655.7221.17.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 X-Miltered: at concorde with ID 43199797.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 43199794.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 ocaml:01 damien:01 ocaml:01 concretely:01 abstraction:01 abstraction:01 widget:01 widget:01 toolbar:98 wrote:01 wrote:01 sourceforge:01 sourceforge:01 widgets:01 X-Attachments: type="application/pgp-signature" name="signature.asc" X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3 --=-7++EPM45+sxRrkfXbpGa Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2005-09-03 at 12:34 +0200, Damien Bobillot wrote: > skaller wrote : [] > If the programmer modify the value of this =20 > variable, the text field is automatically updated to the new value of =20 > the variable.=20 Actually, Tk has done this for years. [] > I don't know if it is implementable in ocaml as is,=20 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=20 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 .. :) --=20 John Skaller --=-7++EPM45+sxRrkfXbpGa Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBDGZd9sRp8/9aGVGsRAkUrAJ9gPrhmPj3jLBQYgfCUpY/jylyKpwCfaN08 q7k9NNIJ7g7W1yaAQxteSxA= =5wLU -----END PGP SIGNATURE----- --=-7++EPM45+sxRrkfXbpGa--