Subject:
Re: Nano-X window manager API
From:
Daniel R Risacher ####@####.####
Date:
19 Dec 1999 23:03:02 -0000
Message-Id: <m2iu1ur14v.fsf@risacher.ebicom.net>
There are two contradictory goals here.
1. Compactness. This would argue for having all window management in
the nano-x process.
2. Modularity & Flexibility. This goal would argue for having window
management handled by a separate process.
This issue is a reflection of another, underlying issue: what is
Nano-X good for?
I claim that there are two distinct types of environments where Nano-X
will be used: embedded devices and lightweight computing. When I
envision using Nano-X for embedded devices, I think of things like
avionics displays, interfaces to copier machines, portable mp3
players. By lightweight computing, I mean things like palmtops, the
Clio, or wearable computers; things that would otherwise be running
WinCE, PalmOS, or EPOC.
Embedded devices often have processors (& OS's) too simple to support
multi-process. But they also have less need for window management!
For just about any of those applications, the client probably knows
where and how big the window should be. For this class of devices,
the support that Nano-X offers currently is probably more than
enough.
But the range of devices for lightweight computing is large and
includes some relatively powerful machines. Having window management
be modular is a big win here, and I think should be moved out to a
separate process for this type of environment. User prefs, memory
size, screen size, and processing power will dictate how big the
borders & titles are, placement and movement policies. It will be
easiest for system integrators to customize these things if the WM is
a separate entity.
So how do we satisfy everyone? My proposed solution would be to push
responsibilty for window management to a separate process for
lightweight computing environments, and assume that applications for
embedded devices will handle their own placement and size issues. To
reduce the memory cost for embedded systems, the window management
support should be conditionally included at compile time. (#ifdef'd)
If I'm not creating a false dichotomy here, then it might even be
reasonable to remove support for borders altogether. Most
applications would let the WM draw their borders, and applications
expected to run without a WM would have to draw their own. I tend to
think this goes too far, personally, but it should simplify things
quite a bit.
>>>>> "Greg" == Greg Haerr ####@####.#### writes:
Greg> Now that Nano-X 's window moving and clipping is fully
Greg> working, I've been thinking of adding some fancy draw code
Greg> to allow Nano-X applications to look as nice as Microwindows
Greg> ones do.
Greg> The draw code would be contained in a completely separate
Greg> file. And there would be a switch so that, if desired, the
Greg> extremely simple look and feel currently present (that is,
Greg> size of border and color of border only) would display as it
Greg> does now.
Greg> The first step is to move out all server-based drawing of
Greg> any border areas to this separate file, and then, develop an
Greg> API so that customized drawing can easily be accomplished.
Greg> (that is, the user can write a window manager).
Greg> Currently, Nano-X uses a rather klugy method of actually
Greg> drawing the border. That is, it temporarily extends the
Greg> window size for clipping, draws, and then shrinks it. This
Greg> causes all sorts of kluge coding when actually writing the
Greg> window manager, because it would be always adding and
Greg> subtracting from the "window size" to create it's idea of
Greg> the "window size". I propose a solution that I'm currently
Greg> using in Microwindows, which BTW would allow us to share ALL
Greg> clipping routines, rather than have separate ones like we do
Greg> now for Nano-X and Microwindows.
Greg> The idea is to keep separate x,y,w,h values for both the
Greg> "user window" and the "window manager window" in the window
Greg> structure at all times. All the window resize routines etc
Greg> keep both these values updated at all times. Normally,
Greg> drawing to a GC will force clipping to the "user window".
Greg> We add a GetWindowGC (used only by window managers) that
Greg> forces clipping to the "window manager window" (which is the
Greg> border area) and it can then easily draw into that area
Greg> using that GC. The window manager can also specify the size
Greg> of the "window mgr window" during GrNewWindow().
Greg> Finally, the window manager can get involved using the
Greg> following logic: if the bordersize is specified as 0, then
Greg> no border is ever drawn. If non-zero, then the window
Greg> manager overrides this value to create it's own idea of
Greg> x,y,w,h for the current look and feel. If the window
Greg> manager is turned off, then the non-zero value is used
Greg> directly and painted in the also-passed border color.
Greg> In the first rev, I don't think the window manager should be
Greg> a separate process, since it'll only be a few hundred lines,
Greg> and all our OS platforms don't always support multiple
Greg> processes.
Greg> Comments?
Greg> Regards,
Greg> Greg
--
You're just jealous because the voices only talk to me.
Daniel Risacher ####@####.####