Opening windows (was Re: [E-Lang] what is good about E?)

Mark Seaborn mrs35@cam.ac.uk
Sat, 28 Jul 2001 20:02:17 +0100


"Marc Stiegler" <marcs@skyhunter.com> writes:

> My current plan for an installer/execution system always gives the
> program the authority to create a window (when would you not want
> the app to be able to talk to you? :-)

As Ken Kahn pointed out, there are times you'd want to restrict the
ability of programs to open windows.  My computer can get quite slow
at times and I often find that if I run a program it takes a little
while for its window to appear.  This can be frustrating because if I
want to do anything in the mean time there is a danger that my typing
or my mouse clicks will go into the newly-opened window instead of the
one I intended.

Ideally, every GUI operation should be tagged with whether it opens a
window, so that if it does, the window can be opened immediately, even
if its contents are not displayed immediately -- at least this gives
the user a chance to switch to another window and then not be
disturbed.  (The screen and input focus make up a namespace, and
programs should not be allowed to modify this namespace
asynchronously.)

For widgets like buttons this should not be a problem, and it has the
added advantage of allowing visual clues of whether a button will open
a window.  However, it does mean that the initial size of the window
needs to be known by the button and not by the program it launches --
not a huge problem, since the important thing is that *some* default
window size can be used immediately.

For a command line interface it is not generally possible to tell
immediately whether a command will open a window.  In this case, if
the user executes a command which returns a capability, it should be
possible to let the user open this capability *as* a window with a key
press.  This would be an extension of the current scheme in which
objects have a Miranda method returning a string representing the
object -- an object could also be able to populate a window to
represent itself.

An object could populate a window either one-off by returning
instructions to create a tree of window-system-provided widgets, or by
drawing directly into the window -- or by providing a redrawer object
that draws directly into the window and that only holds a sensory
version of the original object.  (It would be nice if it were possible
to provide enforced visual clues showing what will modify an object,
though I'm not sure how far this is possible.)

This scheme would make it easy to delegate the use of a window to
someone else, because windows would effectively *be* capabilities.
That is, they would be capabilities to the user, looking at the
screen, rather than to the program, looking from the other side of the
screen.

-- 
         Mark Seaborn
   - mseaborn@bigfoot.com - http://www.srcf.ucam.org/~mrs35/ -

         ``At this moment in time I did not say them things''
                -- Glenn Hoddle