[interfacekit] AtheOS Window Management: A First Look

All right, guys. I obviously got quite a chunk of free time today to do some 
work. I finished work on figuring out what AtheOS does. It's forwarded below. 
If anyone wants the StyledEdit-formatted file I did it in (it's a little 
easier to read), let me know.

--DW

Layers and Management

AtheOS uses a layering system for window management. Each workspace consists 
of a stack of these layers. A Layer can be created using a ServerWindow 
(which requires an application's connection to the server) or a bitmap - in 
the case of the wallpaper.

The class listing breaks down into the following parts:

Member access functions (GetWindow, SetUserObject, etc)
Hierarchy functions (GetParent, GetChild, AddChild, etc)
Coordinate Conversion functions(ConvertToRoot, ConvertFromParent, etc)
Graphics functions (SetFgColor, DrawLine, DrawString, etc)

Data members include:

frame relative to parent
a handle to allow app to access it
various Regions for redraw purposes
Various colors (fore, back, etc)

Also included is the global access function Layer * FindLayer(int Token)

FindLayer is quite useful to the server's implementation of an application (a 
ServerApp). This ServerApp class (SrvApplication in the sources) calls 
FindLayer in order to access its ServerWindow. If I understand things 
correctly, the ServerWindow class can basically be thought of as a rectangle 
on the screen with a number of attributes and properties, such as its 
Decorator (border-drawing class), title, etc. It does not actually have any 
actual drawing-related items aside from its decorator.

We actually don't see much usage of the Layer class for its own sake, though, 
as important as it may be. The Desktop class deals with the layer stack for 
each workspace. The AtheOS app server, when initialized, calls 
init_desktops(), which initializes the graphics driver and creates the bottom 
layer, i.e. where the workspace's background is painted.

The Desktop

The public API for workspace management is a series of C calls. No class 
references are made or necessary, as each workspace is referred to by its 
handle. There is a hard-coded maximum of 32 workspaces. This management API 
is very much designed for event-driven calls, with functions such as 
add_window_to_desktop(), get_active_window(),etc.

A few strange things (to me) exist in this design: that of access to windows 
from a desktop object, layer management, and focus tracking. Windows are 
stored as a singly-linked list, with each desktop object having access to the 
active window and the first window. The ServerWindow class has a pointer in 
it to the next window. Managing layers is done in the same way, but on a more 
complicated level. Tracking focus is done by an array of ServerWindow 
pointers. While keeping pointers makes sense, having a hardcoded limit of 32 
seems unusual. It is easily possible to have more than 32 windows on a 
workspace, even if it does not happen often.

Also in this class is the path to the wallpaper to the class, a pointer to 
the first system window, and screen mode info for that individual workspace.

What I think we need to do

        In perusing this code, I have formed my non-expert opinion on how I 
think 
the Interface Team should implement layer and workspace management. We should 
design a similar API for the workspaces, but make use of BLists for keeping 
track of ServerWindows and Layers. This would cut down on the number of 
linked-list pointer problems at the expense of a little overhead. Also, it 
would allow for much easier access to the ServerWindows when we need it and 
make coding much simpler. Keeping the 32-workspace limit seems acceptable - 
few, if any, will need even that many. The some of the redraw-related members 
of the Layer class seem to complicate things - there are 7 different Regions 
used. If that many are necessary in our implementation, fine, but I think we 
ought to follow the KISS rule.
        Quite a bit of our initial work is likely to be in this area - window 
management and redraw. Of course, handling input might be nice, too. ;^) 
However, there are only a handful of classes which we need to build to get 
that far:

AppServer
ServerWindow
Layer
Workspace
ServerApplication

Decorators are a *very* nice idea - an addon to change how window frames are 
drawn, so we should keep it in mind while coding, but for now, having 
hardcoded frame rendering will get us by.

Other related posts: