lkml.org 
[lkml]   [1998]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: OFFTOPIC: GGI and alternative GUIs and windowing systems in Linux -LONG
Date
> 
> I'd be interested in seeing your "manifesto".
>
> jason
>

Here it is: [apologies to the LK list, I've already seen posts about
how it's flawed... :]


Well, now I have to write a manifesto. :)

Well, this all started when I decided that all of the commercial Linux
distributions weren't as commercial as is needed to reach critical mass.
I had decided that a Linux distribution would need a GUI install, much
like the Solaris install. So, I sat down and thought up a wishlist.
At first it was "I don't just want a 2 bit hack running on top of a
4 bit graphics library....". It all snowballed into the idea that Linux
needed a developer friendly, powerful, lightweight, extensible, and
unified user interface windowing system.

See, the one thing that WinblozE has over us is that it has a unified interface
that changes with upgrades in the OS (some may see this as defective, however
it shows a more clever underlying API). With X windows, every program you
use has redone the whole user interface and object management code, this is
fundamentally wrong. The user interface (what graphics are presented to
the user) should be consistent from one program to the other. Yes, Motif
and a zillion other toolkits address this, but they don't address the other
fundamentally braindamaged problem. Every time an event happens in X windows,
a message is sent over a socket to a program polling for events, which then
runs through it's object manager, which then in turn does a callback, which
then sends more messages back down a socket to X, to draw or interact with
something.

Ok, now this model is powerful in that it allows you to succumb to this
braindamage. The ability to make your interface unique is useful, extending
the capabilities of a program is neccessary. Additionally, the ability to
run an X application on an entirely separate machine is even more useful.

I contest that X was designed in such a fashion, as to offload all processing
to the machine on which the application is running. The X client (display)
would simply need to have an over glorified state machine to provide a display.

This model is extremely complex, from the 120 API messages in the X protocol,
to the multiple layering of the Intrinsics to the toolkit. The good points of
the X model can be used in a more efficient fashion than they are now, because
we can assume that the client (display) has some horsepower and memory.

Ok, enough of the backplot! :)

My solution is to move the object management code into the client (display),
and only consult the application when an interactive event deems neccessary.

The way that this is achieved, is to make an X like windowing system (the 7?
core resources are managed similarly as objects) with a base level UI drawing
library resident in the display server. Each UI object would have a number
of "default" handlers for various events. Each window and object would retain
the event mask architecture, this is a Good Thing(tm) that MS fundamentally
ignores (can you believe that they go through the whole rigamarole of passing
a message to a window that's just going to discard it?), and would be created
with default handlers. The default handlers (updating a list box when the
scroll bar is moved for instance) could provide most of the logic in 90% of
all programs, thus reducing the number of events generated to the program,
and making UI response faster, network bandwidth usage lower, and the UI a
unified, design.

Now, to address the extensibilty issue, you would be able to subclass various
core objects in the server, get handles to them, and write subroutines in the
client application to draw and maintain those objects. Basically giving the
ability of creating object, dumbly like X, to the client application. In
addition, you would be able to subclass objects within the server and manage
them within the server (a button class with an image box, for instance) by
telling the server to make complex objects from base objects, etc.

This model also changes the Client/Server reference model of X slightly. In
X, the term client and server must be interchanged to keep coherency in a
document. In this model, the display is a Server in all aspects, and the
client application is much thinner than an X application.

To sum up the differences, X has a thin Server (display) and a fat client
(application). With the model I'm proposing, the server is fatter (display)
and the client is much thinner (application). It is a logical extension to
today's needs, and it retains the lessons we've learned from the past. This
model retains the "network transparency" because it still uses a connection
oriented medium to communicate between the application and the display. It
however takes the interface processing out of the application and puts it into
the windowing system frontend.

Well, that pretty much summarizes what I propose for "Why" windows. I am
interested in developing this idea, because I think that it is time. With
GGI around the corner, much of the actual hardware interface is going to be
an insignificant issue to address, but without something to actually utilize
GGI, it may be relagated to a toy, or gamer freak extension.

Perry Harrington


--
Perry Harrington Linux rules all OSes. APSoft ()
email: perry@apsoft.com Think Blue. /\

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.052 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site