Re: GUI

> >I'm thinking it would be interesting to have a GUI server (two actually)
> >that handle general screen drawing and high-level widgets.
>
> This would be cool (and very Plan9-ish) but MGR asks so little of the VGA
> interface that it's the path of least resistance to link in svgalib. Most
> graphic apps (as distinct from windowing apps) seem to be most efficiently
> written to get a pointer to the frame buffer and information on the
> geometry, and then go at it with memory accesses.

Thinking futher on this, I'm having trouble deciding how the actual event
handling would work out.
My first thought was that each "file" contains an eventsTo property that
specifies ".." by default; the top-level (or whatever is convenient) sets
eventsTo to an application event queue "file", and the application reads
this file. Events in the file would be of the form sourcePath:event, e.g.
"menu/File/Open:select"
The issue is that I'd like to specify handling of certain events per object
in the properties for the object, e.g., I'd like to be able to specify that
a character event of Alt+F delivered to the menu bar invokes the select
event for the File submenu. (I could have a property in the File object for
hotkey="F" of course, but I want something more general.)
This leads me to the issue of should events be considered top-down or bottom
up (top-down meaning that the application main-window receives the event and
passes it down to its children based on its currently focused child or the
position of the event -- the top gets first crack at the event before
passing it down; bottom-up meaning that the lowest-level window gets the
event and passes it up to the parent if it doesn't want to handle it
itself). I've used UI systems with both views and seen advantages in each.
(Note: this is separate from window subclassing; I'm referring here only to
containment.)

Ideas?

I'm also torn between having high-level vs. low-level view of the UI, or
both.
For example, a menu-bar could be expressed as:
menu/ (properties include class=menuBar)
    File/
        Open...
        Save
        save As...
        Exit
    Edit/
        Cut
        Copy
        Paste
    Help/
        About...

Making the menu from a script consists of mkdir and touch commands (along
with stat -w commands).
This is a good level for an application to view the ui. For the server that
renders the UI, it is less convenient, requiring the server to understand
all widgets.

Or it could be expressed as the low-level horizontal array of buttons and
pop-up submenus (which are vertical arrays of buttons, etc.) that a menu bar
really is.
In this case, creating a menu would best be done by copying from
higher-level templates:
cp -R /ui/templates/menuBar /ui/application/myApp/menu
cp -R /ui/templates/menuBar/item /ui/application/myApp/menu/File
cp -R /ui/templates/menu/item /ui/application/myApp/menu/File/Open
This is a convenient level for a UI rendering system to view the ui (it need
only know UI primitives such as rectangles, borders, and horizontal and
vertical arrays); but this is less convenient for the application.

Of course, if one must choose convenience of application vs server,
application should win (many applications, one server (per display device
type)). However, I may be able to have my cake and eat it, too. I could have
a high-level widget server that supports a high-level view (with
class="menuBar" and such). I could then have a template (or script) for each
class that is used to create the corresponding low-level view. A separate
low-level server would use the low-level view to render the ui in terms of
the primitives (this would be the low-level display server I mentioned
earlier).

Or perhaps this low-level view as a filesystem is really an exercise in
molding a square peg to fit a round hole. Rather than doing high-level fs to
low-level fs to low-level graphics api mapping, I could go straight from
high-level fs to low-level graphics api. The former is more in keeping with
"everything is a file," but is it gatuitously so? (I do find it interesting
to have the high-level widgets really just be scripts/templates that
generate a corresponding low-level view, though.)

Now, while I still find it appealing to create and interact with a UI as a
filesystem, I'm now questioning whether it's really more intuitive or
straightforward than the simple UI APIs offered by Tk and similar libraries.

Opinions?
Received on Sun, 29 Feb 2004 19:21:14 -0700