[haiku-appserver] Re: Refactoring

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Tue, 28 Jun 2005 11:05:04 +0300

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.

I just read again your "Desktop" description. I agree with it. However, there's a catch: you should be able to pass an app/window from one user to another. Some settings for applications/windows should be kept globally.

The name TopLayer can easily be confused with RootLayer.


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.

"Every Workspace may have a different resolution"
Not a screen configuration.
Workspace should have a pointer to a VirtualScreen(n Screens) object. This lets you have 1,2,3,..,32 VirtualScreens attached to a RootLayer object, and every Workspace have that pointer to one of them(as set by a configuration (tool)).
( it would be nice (IMO) to have these classes: Screen(virtual), PhysicalScreen(mapped to a monitor), VirtualScreen(a spread screen composed from n PhysicalScreens) )

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.

Um... I think it always did. Don't have BeOS at hand, but I'm pretty sure move or resize operations are "mirrored" in other workspaces.

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?

Well... because it's not needed. But I think we just agreed on this one below.

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.


But even then, one RootLayer for each screen would be needed, right?

IMO, no.
It seems we have different understanding of what RootLayer is. I understand RL as a virtual surface onto which WinBorders are drawn. This surface can be made from lots of small surfaces which are exactly the physical screens.

As you said: RootLayer should manage WinBorders only (with the help of 32 Workspace objects, i understand?). If you want a RL for every screen, how would you be able to have it spread across 3 physical screen, for example?

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.

Axel, IMO, what remains to be agreed on is the Workspace/Screen/RootLayer stuff. Expecting your response on what I've said above.

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
[00:54] <darkwyrm> axeld double yuck

Didn't we agreed at one time, region rebuilding should be done in one thread only, RootLayer's one?

About the IRC meeting. Sorry, I can't attend, it's just too late for me. In the first place I don't know the hour at which it begins. I suspect int 00:00 CET. This is a little late for me as it's 1:00 AM in Bucharest. Sorry.

bye, Adi.

Other related posts: