Subject:
(long) discourse on nanogui design
From:
Greg Haerr ####@####.####
Date:
11 May 1999 22:14:28 -0000
Message-Id: <01BE9BC9.A61469C0.greg@censoft.com>
comments follow
On Tuesday, May 11, 1999 1:04 PM, Vidar Hokstad ####@####.#### wrote:
> On Tue, 11 May 1999, Greg Haerr wrote:
>
> > I agree that the window mgr should be modular, but if you want different window
> > managers, you might as well use X. Actually, although it was a good idea,
> > the fact that X's design allowed for so much flexibility with differing looks and feels
> > contributed to Microsoft's taking over with their faster, more consistent gui...
>
> Why not do the same as with the display "devices": Use a jump table. That
> way it's a minor issue to add a compile time option for including
> code that uses dlopen()/dlsym() to load an external module for those that
> prefer that to linking in a window manager at compile time.
Oh yeah, definitely. Ultimately in a small system this can also
be handled by just having a definite Window Manager internal API that is also
kept in a separate source file set, living "on top" of the lower level graphics stuff.
In a way, this is the way I hope to handle it.
The other cool thing is at this point in the design, the key is to get well-known
api's defined, and the stuff underneath/beside it working, so that other folks
like yourself can start contributing and making the project better, without
getting in the way of each other... That's the fun in early architectures of small
engines!
>
> > The first version of nanoX that I write will definitely have some built-in window
> > management, in order to keep it small. In my opinion, *all* of nanoX should be
> > kept small, so that it can be used where X can't. Otherwise, why not just use X?
>
> I agree..
>
> Just one issue: Make sure the system still works fine without any window
> manager, the same way X does.
This might be a good place to make a major point, after reading all the good discussions
about nanoX today.
Today, I view the nanoX project as a couple really cool things: one, a repository
for some lower-level drivers that are definitely needed for a place a programmer to
go to do some low-level stuff like get some strange card to switch to graphics
mode and support some graphics layout. Believe me, we have a long way to
go if we want to support all this fancy GDK and X Widget stuff, by getting some
organized approach for algorithms like text draw, pattern fill, bitblt routines, font
loading, XOR line draw, etc. All these things I have said before really need to be handled by low
level code that knows about the hardware. By building a low level device api,
we can get people contributing in this much needed area.
The second cool thing is to build a mid-level api that loads these drivers,
and manages the next set of needed algorithms, like bresenham line draw,
ellipses, polygons, area fills, and clipping. These routines are device-independent.
Ideally at this level we haven't got ourselves stuck to an archtecture like X, Windows Gdi,
or GDK. This is just still mid-level graphics stuff that anyone can use for anything,
although most people don't yet.
The "nano" side starts slowing down here. This is a base toolkit that
allows anything graphical to be written to run on anything.
Nano-X then is a project that uses the nanogui engine to implement an X-like
API along with basic window-management functionality for folks that want a useable
subset of X Server functionality, not necessarily requring a network or TCP/IP.
The GDK stuff could then be built on top of nano-X, or it could be built directly on the
nanogui engine, depending upon design requirements.
You're all going to think I'm crazy, but I want to write nano-Win, which will
be the first *small* implementation of the MS-Windows win32 GDI api along with
window management that will run on *anything*, especially systems *not* running
MS code. There are countless applications written using this user-level graphics api.
A point on window management: much of an application's event-driven
behaviour and coding depends on the architecture imposed by window management.
This means that the window-management architecture generally needs to follow
the user-level api that programs are going to be written around. Conversely,
a graphics system without any window-management semantics ultimately is
just a set of graphics driver calls whose semantics are wholly controlled by the
user-written applications program.
Hopefully the design ideas presented here will allow everybody to have their
own graphics cake and eat it too...
Greg
>
> For our use, for instance, we don't want the windows to be movable or
> resizable for the end user, and we don't want any visible borders
> stealing screen real estate, and I suspect that to be valid for a fair
> share of the PDA/set top box/webpad market.
>
> Vidar Hokstad ####@####.####
> Director of R&D, Screen Media AS
>
