From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <991d76cb3b0fe028c65b68c44569136f@9netics.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Evolving rio / GUI development
Date: Mon, 21 Feb 2005 16:37:37 -0800
From: Skip Tavakkolian <9nut@9netics.com>
In-Reply-To: <700cc765c1dd7da842f38406724bd476@proxima.alt.za>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Topicbox-Message-UUID: 50a016e0-eace-11e9-9e20-41e7f4b1d025

>> Autocad started as a lisp interpreter I think and many professionals p=
refer the
>> commands to the placing stuff with the mouse or at least combine both.=
..
>=20
> Dotty (from graphviz) still operates on that principle.  So it's not
> as if there is only one scheme of things.

My preference for the whole gui approach would be to have it cleanly
separated from the applications.  Following /dev/draw's model, ideally
a filesystem would enforce the GUI=E2=86=94application interface.  A
refinement (not a new idea either) is to tie the whole "chrome"
filesystem to a language like tk/tcl; tcl or lisp/scheme would not be
my choices.

If the chrome could be cleanly detached from the underlying functions
and could be changed easily, look-and-feel development could continue
well past the time when it's functionality is complete.  If someone wante=
d
eye-candy, he could develop it.  Perhaps generalizing the interface is
not possible and would require specialization to specific problem
sets.