replacement for x

[Shawn T. Rutledge]

On Sun, Nov 05, 2000 at 10:34:04PM -0800, Roger Prutsman wrote:
> Does anyone know of any possible replacement for X in
> the future? I have used several window managers and
> each have strengths and weaknesses. What would be
> ideal is a window manager that supports all widget
> sets and is small, quick and stable. Yet no matter how
> small the wm footprint, it must sit on top of X, which
> is large and cumbersome. I don't have the most modern

Yep.  This is why I started writing a sort of NeWS-like
system which will use 100% Postscript as the on-the-wire protocol
for both drawing commands (and much higher-level drawing commands
than X, at that) and also events going back to the server (the 
"client program" in X terminology).  But I haven't gotten very far
yet; I have a simple interpreter with a few operators working, a lot
of data structure work is done, and I temporarily hacked in some 
graphics operators via calls to the X library... next will be to
actually store the "shape so far" in a shape structure, implement
transforms, and be able to handle the "expose" events by repainting
the current shape.  But I didn't have time this weekend, too many 
other projects.

The point of this exercise is to create a much higher-level display
system; applications will simply be able to request widgets, or
even entire reusable "application views", and the client will be
responsible for rendering them.  (However, some of the machines
with really limited resources might need to rely on a "middleware"
server to predigest their Postscript a bit.)  The look-and-feel will
be controlled entirely by the client.  This will mean that you will
not be stuck with the ubiquitous overlapping 2D windows; you could
have more complex or less complex renderings for different classes
of devices, with no change to the applications.  You could even combine
several machines into a "virtual workstation", for doing multi-head
work without special hardware.

The initial thought which led to this idea is that most widgets in
most applications are just means to execute commands.  Menus, toolbars,
right-click menus, tool palettes, etc. all have the same purpose - 
you click and the application gets notified and does something in
response.  Usability experts preach that consistency is the most
important thing about designing the arrangement of the widgets
in an application; so really it shouldn't be left up to the programmer
at all.  The GUI framework should enforce the consistency.  The 
programmer will be able to just specify that such-and-such object
is to be put on the screen, and it has associated with it this tree
of commands which can be executed, each with a "visibility" or "priority".
The client implementation will need to make sure that the highest-priority
commands are the most visible/accessible.  How that is done varies
depending on whether the user is using a mouse, a touchscreen, a
stylus, or physical buttons and other controls; how much screen
real estate is available; etc.  And the user will be in control a
lot more too; he'll be able to change the rules to suit his own
taste instead of being stuck with the bad decisions of the application
programmer, and those changes will be applied to all of the 
applications.  I call these high-level GUI descriptions "metawidgets."

There are also several really common application types: rich-text
editing, structured drawing/diagramming, and pixmap editing (and
a few more, but those are some fairly complex types I can think of).
For these applications, the entire "view" (the "V" in the MVC pattern)
will be reusable across all applications of that type.  It will
be implemented in Postscript and run on the client.  That will
make it much less trouble to write these applications, and programmers
can concentrate on making smarter models behind them... which is
an area that needs a lot of work in most of the applications of
this type that I have seen.  Especially the freeware ones.

The X implementation is just a convenient place to start; I intend
to implement it on a variety of platforms including the linux 
framebuffer, DOS, MacOS, and various PDAs if it ends up small 
enough.  It will be a great way to reuse old machines as thin
clients.  I don't know how small it can be; it's not simple enough
to be really tiny, but I'm trying to write highly optimized code,
and might also end up leaving out some Postscript features if they
would lead to bloat.

But it might be quite a while before I get it into a useable state.
In the meantime, there is VNC, and various old GUI systems which could
perhaps be resurrected... (GEM, MGR, etc.) but most of those are not 
client-server.  There is Berlin but it is shooting for advanced features
rather than small size.  The use of Corba pretty much dooms it to be
kindof big.  There is that RIP system that used to be used for graphical
BBSs (like Prodigy in the early days)... I seriously considered using 
that at one point for thin-client stuff, but it has a lot of limitations.
VNC is probably the best all-around.  It will run on a 486 well enough.

-- 
  _______                   Shawn T. Rutledge / KB7PWD  ecloud@bigfoot.com
 (_  | |_)          http://www.bigfoot.com/~ecloud  kb7pwd@kb7pwd.ampr.org
 __) | | \________________________________________________________________
 Free long distance at http://www.bigredwire.com/me/RefTrack?id=USA063420