[haiku-appserver] Re: Refactoring

  • From: Adi Oanca <adioanca@xxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Mon, 27 Jun 2005 20:31:13 +0300


Axel Dörfler wrote:
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 :)

I don't think they are complicated.

        No, no I don't think you're dumb! :-))

        I just think you don't understand them, yet.

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

Yes, in some cases.

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. :-)

        Let me explain a bit.

Desktop - only one instance, manages BApplications, and general things about the application server (fonts, available decorators, virtual screens(ServerScreen), etc).

ServerScreen a virtual screen. It's composed from 1 to n physical display_cards.

RootLayer - one instance for every user. It is very similar to a Layer, the only exception is that it "emulates" its children. It does that by using a Workspace object (32 in fact) which is responsible for keeping windows in the right order.
Every RootLayer has attached a ServerScreen object (only 1?) which it used to present what a user would call... Desktop.

WinBorder - name is bad. Should be changed. In fact, WinBorder should disappear. It should be replaced by TopLayer, a Layer which represents the blank area from the client side (top_view).
ATM, there's WinBorder with a special Layer as the root of all window's views/Layers. One of the two is pointless. (Remember Axel, when you asked me: why do we need a top_view?)

Workspace - manages window order and focus. This should only expose public methods like Set/GetBGColor, Set/GetBitmap. Those related to WinBorders should be private and used by RootLayer only. ATM, if one calls a Workspace method which has something to do with the window order/focus nothing will happen, I wanted this to be a separate module which should have nothing to do with displaying things on screen.

Anyway, things are not final in my mind also, and I'm very open to improvements/designs.

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.

the desktop color, and keeps track of which windows are part of the workspace.

This I agree.

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.

This is no problem as long as a ServerScreen object would do it's job.

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.

Let's not pass beyond the attributes that a workspace has.
If you want to have the same window on both physical screen and want to move one of them and the other should stay, then it's clear you need another RootLayer and WinBorder instance (one that is used by you of course, the 2nd one). The window content will be mirrored. Still, why would you want this? Any use of it?

They may have different resolution/color space.

This is a problem. More talk is needed. Why shouldn't all screens have the same resolution/colorspace?

How should Tracker be able to draw the background image?
Should it be stretched over both, or duplicated, like in Windows?

I think duplicated would be nicer.

And how should that be realized with the current API?)

Um... we have to think. :-)

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. :-)

3) WinBorder: the look and feel, the decorator, etc. is handled by ServerWindow - WinBorder only cares about the frame, and nothing more.

I don't think it's OK. ServerWindow is BWindow's counterpart. It manages a communication channel and dispatches messages.
We need a Layer subclass to do what you described above. What do you think about the TopLayer proposal.

WinBorder::Draw() would get the decorator from the window.

:-) nice idea. But let's make it: Decorator::DrawDecorator(Bitmap*)

Every ServerWindow has as many WinBorders as it has workspaces.

Don't think it's a good idea. As I said, let's not pass beyond a workspaces attributions.
(still, it feels a bit weired when I have a window in 2 workspaces move it one of them and it appears moved in the 2nd one. I would expect it to be where it was when I changed workspace and back again :-) )

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.

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.

I think ServerScreen should present a virtual screen and manage N DisplayDriver instances.

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

Let's talk more and we'll see what it comes out. :-)

bye, Adi.

Other related posts: