[haiku-appserver] Re: Refactoring

> 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 :)
Nope. They're complicated. I've always thought so, too, but that's 
because the server's got a lot of stuff to manage.

> Anyway, the distinction between RootLayer, Desktop, Screen, and 
> Workspace is a little strange, and looks a bit broken, too, in many 
> details.
> 
> Well, here is what I would find a useful separation:
<snip>
> 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 
> simple.
> Every screen (in every workspace) gets a separate RootLayer object.
These are R2 issues, really. The details of handling multiple monitors 
are something that I need to figure out so that it doesn't require much 
effort to work well and yet can be quite configurable for us power 
users. :D

> 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 
> future).
> 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 
> attached).
What you have described is pretty close to what is currently in place 
AFAICT. While it's been quite a long time since I played around with 
the window management code, unless I remember wrong, RootLayer is the 
root layer for all layers and there is a 1-to-1 relationship of 
RootLayers to users. Workspace is a lightweight class that just manages 
settings like color depth and resolution and boils down to a list of 
windows that it displays. This makes it possible to implement 
B_ALL_WORKSPACES, for example.

--DW

Other related posts: