BS'ing about 3B1 windows

[Jim Rosenberg]

Lately there's been a bit of talk about porting X to the 3B1, with the
consensus seeming to be don't hold your breath, X is humongous and a port
of X will take a while.  I wonder whether we might be able to come to some
consensus on what's wrong with our existing ua and windows interface, just
what we'd like to see in the way of windows, and how much work it would be
for a quick hack that might give us more functionality than we've got now
without all the work of porting X.  So here goes.

         What I Don't Like About the Existing Windows Interface

I can say this in a single word:  borders!!  The concept of window borders
is just too inflexible, and the borders are too big!  What I really want is
windows that can be:  (1) moved & resized with the mouse (2) are large enough
for an 80-column line (3) in a font that's not so small I'll go blind using
it all day long.  The smallest size AT&T seems to think you should use for
serious stuff is 9x12, but with a 9x12 font and a bordered window there
isn't enough room for 80 columns.  (A font that is say 8x10 would help a lot
-- does anybody have such a beast?)  The existing interface makes the mouse
useless with non-bordered windows.  You can use windy to make the window
parameters anything you'd like, but this is a horrible way to have to move
or resize windows.  My personal view is that the side borders should be just
a thin line, not the huge awful things we have now.  Use a thick title bar
at the top, have move and resize icons at the top.  Clicking the title of
a menu could bring up a menu that would allow other options.  The thick
border on the left is a completely useless abortion that serves no purpose
except to take away **MY** pixels.  The thick border on the right seems to
be mainly used as a place to park the scroll icons.  Note that 3B1 scroll
icons are a pretty paltry thing compared to genuine scroll bars, which would
be pretty nice.  But real scroll bars are a pretty serious effort, that
would require redoing how the whole window driver works.  I.e. all output
to a /dev/window device would have to be buffered, so that when the scroll
bar was moused screen areas could be recovered.  The Mac II AUX scroll bars
are pretty nifty, I might say.

Now this brings up the whole question of ua.  I frankly don't use ua, but
run multiple gettys on /dev/window.  I know a very great deal of work went
into ua by reasonable people, but frankly I feel the whole premise of ua is
deeply misguided.  The philosophy of ua seems to be that UNIX is just fine,
thank you, and all that's needed is a prettier face to slap onto the real
meat, which is shell scripts.  ua misses the boat completely.  That boat is
that a user interface should be object oriented and programmable with as
much power as UNIX gives you through the shell.  The idea that the set of
icons that can appear in a window border is hard-wired into the driver is
just preposterous.  If you think about the Mac Toolkit and ask what is the
3B1 Toolkit the answer is simple:  there isn't any!  I guess the Mac interface
is just as closed as far as what can go in a window border, but it somehow
gives a more open feel.  I've been playing a bit with a Smalltalk dialect
(Smalltalk/V on Mess-DOS) -- Smalltalk is immense, as large as UNIX at least.
I.e. a Smalltalk interface is extensible and the source is all there; the
set of classes you get off the shelf is at least as large a universe as the
set of UNIX utilities.  Incidentally the Smalltalk/V window interface has a
thick title bar but the other window borders are just lines; window operations
are done by clicking the right mouse button on the title bar, which pops up
a menu that lets you move or resize a window, cycle to the next window, close
the window, or collapse it to just the title.  The only thing about this
that I find inconvenient is that to cycle through windows you have to move
the mouse a lot, from one title bar to the next; but on the whole it's a
pretty cute interface and beats the living daylights out of what we've got
now on the 3B1.  Which brings up the subject:

           What Can We Do as a Cheap and Dirty Quick Hack?

windy works just fine in a child process.  That means that a child process
can issue ioctl()s to a file descriptor to manipulate the parent's window.
It seems to me that this means a daemon should be able to manipulate the
windows for clients by opening /dev/w* and issuing ioctl()s.  Presumably a
user-level process could use the mouse to pop up rectangles for moving and
resizing windows.  There's nothing much we can do about the thick borders,
but maybe a new window daemon could make all windows borderless and keep
an extra window for itself.  The window daemon would paint window borders
in this window.  By doing this we would still be able to use the existing
driver, and could have whatever flexibility we wanted in terms of icons,
pull-downs, pop-ups, or whatever.  This is obviously drastically less work
that writing a whole new window driver.  To do things like scroll bars it
would sure be nice to have streams, and I can live without scroll bars,
though they *are* nice.  Scroll bars should arguably be implemented with
libraries at the applications level, anyway.

Comments??

(Aside:  3.51 comes with layers.  The AT&T 630 is pretty expensive (about
$2400) but no more expensive than a monitor and controller at the same
resolution for an AT.  Is anyone using a 630 on a 3B1 with layers?  Does
it work with the layers stuff we've already got?  The *REAL* problem of the
3B1 is that we just don't have enough of those pixels!)
-- 
 Jim Rosenberg
     CIS: 71515,124                         decvax!idis! \
     WELL: jer                                   allegra! ---- pitt!amanue!jr
     BIX: jrosenberg                  uunet!cmcl2!cadre! /