[haiku-appserver] Refactoring

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: "Haiku app_server" <haiku-appserver@xxxxxxxxxxxxx>
  • Date: Mon, 27 Jun 2005 14:00:07 +0200 CEST

Hi there,

I had a little look at the RootLayer/Desktop/... app_server classes 
yesterday, and found them very complicated. That might be attributed to 
the fact that I'm dumb, but I guess it's not just that :)

Anyway, the distinction between RootLayer, Desktop, Screen, and 
Workspace is a little strange, and looks a bit broken, too, in many 

Well, here is what I would find a useful separation:

1) Desktop: this is the real root class of a user's session. Since 
there can be only one user at a time right now, we only need one of 
It manages the whole desktop, including: tracking of user's apps and 
windows, the look&feel settings (ie. colors, decorator, and scrollbar 
info), input (ie. mice and keyboards), and output (ie. screens & 
When a new user logs in (ie. right now, once on startup), a desktop is 
created for him; the user's apps will only talk to the desktop, not the 
app_server anymore.

2) Workspace: the workspace class contains a configuration for each 
screen attached, the desktop color, and keeps track of which windows 
are part of the workspace.
If there is more than one screen attached, the workspace would span 
over both of them - that of course, is not supported yet, anyway, so it 
could be ignored. The problematic part of this is in the details (ie. 
what to do with windows that are visible on both screens? They may have 
different resolution/color space. How should Tracker be able to draw 
the background image? Should it be stretched over both, or duplicated, 
like in Windows? And how should that be realized with the current API?) 
Maybe we even should ignore this part for now (as I would guess it 
needs further discussions, but that's probably your call), and keep it 
Every screen (in every workspace) gets a separate RootLayer object.

3) WinBorder: the look and feel, the decorator, etc. is handled by 
ServerWindow - WinBorder only cares about the frame, and nothing more. 
WinBorder::Draw() would get the decorator from the window. Every 
ServerWindow has as many WinBorders as it has workspaces.

4) RootLayer: the root of all layers for one screen/workspace. On top-
level, it accepts WinBorders only.

5) Screen: manages a single screen entity, and also contains its 
display driver as well as its hardware interface. When we have a proper 
multi-head hardware interface, this might need to be changed, though, 
whatever it will look alike.

How does that sound, and what have I forgotten about? Pros/Cons?

Since we only have one screen right now, and if you think the WinBorder
/RootLayer change is too radical, we could also keep one RootLayer 
object per desktop as well as one WinBorder per ServerWindow for now 
(but I hardly see a clean way around multiple WinBorders in the 
For the same reason, the question of what is a workspace exactly could 
be postponed as well (as it doesn't matter a lot with only one Screen 


Other related posts: