[haiku-appserver] Re: Refactoring
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Mon, 27 Jun 2005 22:35:33 +0200 CEST
Adi Oanca <adioanca@xxxxxxxxxxxxx> wrote:
> Axel Dörfler wrote:
> > 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! :-))
Hehe, I obviously asked to much for this :-)
> I just think you don't understand them, yet.
Probably not completely, but I think I more or less do. But you might
be mistaken as well: I just wrote what I think how the classes should
look alike, not how they look like now.
But I revised it a bit after your explanations, anyway, I didn't take
everything into account yesterday (it was quite late already...).
> > 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 :-)
> 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.
If that's what it should do, it's very broken.
> 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.
I don't see any reason why the RootLayer class should do all that.
> 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).
I am not so sure if WinBorder is really that bad a name - after all
it's the layer that contains the window and the decorator, or am I
wrong about this?
The name TopLayer can easily be confused with RootLayer.
> 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?)^
Yes, I do, although the context was quite different :-)
> 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.
Well, I just explained what I want to change; I didn't want to give a
review of the current status quo.
> > 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.
[...]
> > 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.
That's not really in the realm of the Screen class. It should be (more
or less) the server side BScreen class, and it should therefore
represent a single physical screen which might or might not be handled
by a different graphics card (the current driver API does not yet
support multiple heads, though, so one screen per card is what we could
deliver right now, without any headaches coming from that direction).
> > 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. It only adopts the position from the
previous workspace if the window didn't have a configuration in the new
one yet.
Despite that, I don't think the current API allows for having this kind
of setup (Be API). However, it allows for "1 workspace contains
configurations for all available screens".
> Let's not pass beyond the attributes that a workspace has.
Well, we certainly know the properties of the current Workspace class,
but that don't necessarily mirror what a Workspace is.
> 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?
Deskbar, Tracker. But I just wanted to mention it anyway, I don't think
it's something we should persue. I think that a workspace defines the
configuration of all screens available.
> > 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?
See other mail, there is definitely no way around that.
> > 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.
Yes :-)
> > And how should that be realized with the current API?)
> Um... we have to think. :-)
We don't really have to - it's not possible :-)
What's possible to do with the current API is what I think is the best
solution anyway (as written above).
> > 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. :-)
You just gave me an overview about what's currently done, but that's
what I don't like and what I tried to improve with the suggestions in
the original mail.
What exactly don't you like about this approach?
> > 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.
Huh? WinBorder is a layer subclass, and it should stay this way. But
like a BWindow has a feel, the ServerWindow has one, too.
But since the WinBorder is part of the view hierarchy, I now agree with
you: there should only be one, and then it can well manage what it
manages now.
> > 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?
> > 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.
Yes, actually, I think that was not a good idea.
> (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 :-) )
That's how it's actually done in BeOS, and that's how we should do it
as well (as you said, it's what one would expect).
> > 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?
> > 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.
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.
And then, it would not be a counterpart of BScreen anymore.
> > How does that sound, and what have I forgotten about? Pros/Cons?
> Let's talk more and we'll see what it comes out. :-)
Okay :-)
Bye,
Axel.
Other related posts:
