[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
details.
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
them.
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 &
workspaces).
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
simple.
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
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).
Bye,
Axel.
Other related posts:
