[haiku-appserver] Re: Refactoring
- From: Adi Oanca <adioanca@xxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Mon, 27 Jun 2005 20:31:13 +0300
Hi,
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:
