Axel Dörfler wrote:
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.
:-) RootLayer is that. :-)
And not only that, and that's the biggest part of the problem, anyway. RootLayer does *way* too much. That's why I titled this mail with
"Refactoring" - I think it's really needed :-)
Hey, I agreed on that too. It does *too* much.
The name TopLayer can easily be confused with RootLayer.
OK.
2) Workspace: the workspace class contains a configuration for each screen attached,
Um, I don't know if it's OK, I would say this should be the job of a ServerScreen object.
No, the Workspace has to store a screen configuration - the Screen object only has a current configuration which is equal to the one of the active Workspace.
Every Workspace may have a different resolution.
The problematic part of this is in the details (ie. what to do with windows that are visible on both screens?
Ah, if you have 2 screens, you want a workspace x be mapped to screen 1 and workspace y be mapped to screen 2?
I thought about that, but I was mainly concerned by a spread virtual screen. Here, we might have RootLayer to 2 or more ServerScreen instances and map workspaces to them.
Suppose that was what you were saying, yes, why not? there are two workspaces isn't it? If the window moves in one of them, it moves in the other also.
No, it doesn't, and it never did.
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.
No, I don't like this approach. I would like you to analyze what I wrote above. Maybe it will change your mind a bit. :-)
What exactly don't you like about this approach?
WinBorder::Draw() would get the decorator from the window.
:-) nice idea. But let's make it: Decorator::DrawDecorator(Bitmap*)
I don't understand what you're targeting at. The decorator already draws into the display using the display driver - it doesn't have to know what a bitmap is, or does it?
Misunderstanding. :-)
4) RootLayer: the root of all layers for one screen/workspace. On top-level, it accepts WinBorders only.
Don't need a RL for every workspace. One is enough for your purpose also.
Yes, that's true. Since Windows can also be part of several workspaces, it's probably better to have only one root layer as well, or things would get even more complicated.
Yes.
But even then, one RootLayer for each screen would be needed, right?
I think ServerScreen should present a virtual screen and manage N DisplayDriver instances.
That would only work if it could present a coniguous and homogeneous canvas, which it cannot since every physical screen can have a different resolution and/or colorspace.
Correct. My bad.
What about threads? DW, why you say: [00:53] <axeld> darkwyrm: okay, I'll try to explain: he creates a BPortLink, writes to it, and enqueues the link into a message queue of RootLayer [00:54] <darkwyrm> axeld double yuck ?
bye, Adi.
