nanogui: Thread: Nano-X window manager API

Now that Nano-X 's window moving and clipping is
fully working, I've been thinking of adding some fancy
draw code to allow Nano-X applications to look
as nice as Microwindows ones do.

The draw code would be contained in a completely
separate file.  And there would be a switch so that,
if desired, the extremely simple look and feel currently
present (that is, size of border and color of border only)
would display as it does now.

The first step is to move out all server-based drawing
of any border areas to this separate file, and then, develop
an API so that customized drawing can easily be accomplished.
(that is, the user can write a window manager).

Currently, Nano-X uses a rather klugy method of actually
drawing the border.  That is, it temporarily extends the
window size for clipping, draws, and then shrinks it.  This
causes all sorts of kluge coding when actually writing the
window manager, because it would be always adding
and subtracting from the "window size" to create it's
idea of the "window size".  I propose a solution that
I'm currently using in Microwindows, which BTW
would allow us to share ALL clipping routines, rather
than have separate ones like we do now for Nano-X
and Microwindows.

The idea is to keep separate x,y,w,h values for both
the "user window" and the "window manager window"
in the window structure at all times.  All the window
resize routines etc keep both these values updated
at all times.  Normally, drawing to a GC will force
clipping to the "user window".  We add a
GetWindowGC (used only by window managers) that
forces clipping to the "window manager window"
(which is the border area) and it can then easily draw
into that area using that GC.  The window manager
can also specify the size of the "window mgr window"
during GrNewWindow().

Finally, the window manager can get involved using
the following logic:  if the bordersize is specified
as 0, then no border is ever drawn.  If non-zero, then
the window manager overrides this value to create
it's own idea of x,y,w,h for the current look and feel.
If the window manager is turned off, then the non-zero
value is used directly and painted in the also-passed
border color.

In the first rev, I don't think the window manager should
be a separate process, since it'll only be a few hundred
lines, and all our OS platforms don't always support
multiple processes.

Comments?

Regards,

Greg

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                                   ####@####.####