[interfacekit] AtheOS Layers, Windows, and Bitmaps (Oh my!)

Here's some more bathroom reading for you guys. :^P

AtheOS Server Classes

        Kurt created certain internal classes for his app_server which are 
similar to those in the regular API, but have somewhat specific roles, as we 
will see. He created Server Applications, Windows, Bitmaps, and Sprites - 
which are not discussed here. Below are somewhat-detailed explanations of 
each for AtheOS and how I think they ought to be used in the OpenBeOS 
app_server.

Server Layers

        Layers under AtheOS are utilized to do window management, as briefly 
discussed in my posting on  layering. One could say that it is a fundamental 
class - each workspace is simply a collection of layers. What is a layer? 
AtheOS uses a method for managing windows by simply looking at them like they 
were like little pieces of paper in large sheets of laminant (or clear 
contact paper). No two windows can be right beside each other in the stack, 
even if they appear to be. Moving windows around in the stack is simply a 
matter of juggling a few pointers and redrawing the dirty regions.

There are two constructors for the Layer class (direct copy from the header):

Layer( SrvWindow* pcWindow, Layer* pcParent, const char* pzName, const 
os::Rect& cFrame, int nFlags, void* pUserObj );

Layer( SrvBitmap* pcBitmap );

        Without having done extensive work in looking at the code, it's 
probably 
safe to assume that the SrvBitmap* constructor's primary use is to create the 
top layer for a workspace, although without some serious rabbit-chasing it's 
unclear whether this version is used for much else.
        The other version is likely used most of the time, with a window 
associated in a 1:1 relationship - one window for each layer. This allows us 
precise control of which windows belong where in our window stack. This is 
quite useful when an app has several windows with the B_FLOATING_WINDOW  
window type, for example. Sometimes micromanagement is not such a bad thing. 
:^)

Server Windows and Applications

ServerWindows and ServerApplications seem to be proxy classes for the 
app_server for easier management. They encapsulate data to give the 
app_server less to have to think about. Some might asking, "Why not just make 
the Window class part of the Layer class?"  at this point. When updates are 
made, layers have the capability to access the graphics driver's accelerated 
functions, unlike the regular app. Applications started by the app_server 
communicate with the server quite a bit, such as for Drawing API calls, but 
not always. This could be likened to a mother telling her child to draw a 
picture, but sometimes the child asks her, "Could you help me with this, 
Mommy?"
 
The Desktop

AtheOS' desktop is simply a collection of layers. While, theoretically, one 
could try to hunt down and kill the thing, it is a nice thing to remember 
that these classes are internal and pretty well-encapsulated. Developers will 
have nothing to do with any of this craziness, thankfully.

What do we do?

Well, I think a similar approach is necessary. Using these internal classes 
to help handle messaging and updates should provide fewer headaches. The 
desktop should simply be a BList (for nice & easy changes on-the-fly) of 
Workspace classes. These workspace classes contain BLists for focus lists, 
the  layer stack, and basic screen configuration data.

Other related posts: