[haiku-appserver] Re: Refactoring
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Tue, 28 Jun 2005 13:36:56 +0200 CEST
Adi Oanca <adioanca@xxxxxxxxxxxxx> wrote:
> Axel Dörfler wrote:
> >>>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.
Okay, what kind of settings are you talking about?
> > 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.
> Not a screen configuration.
Well, what makes a screen configuration? Right now, this is just
display_mode. With support for multiple screens, the physical
orientation of the screens would be part of this as well.
The physical screen however, only needs to know about its display_mode.
But that information must be stored in the Workspace object, or else it
would be lost between switches.
> 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) )
Why the effort? What's wrong with just Screen (or PhysicalScreen)
objects? A VirtualScreen and a PhysicalScreen would have very little in
common, anyway.
The app_server would need to have a list of physical screens. The
Workspace object would need a list of screens that the current user may
use at a moment (which will be the same most of the time, anyway) and
their configuration (ie. display_mode, orientation).
> >> 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.
Only resize operations are, as those would affect the BViews in the
window. The position is maintained per Workspace.
[...]
> > 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?
Yes, I think you're right. I always assumed that RootLayer could only
handle a homogeneous canvas, ie. same resolution/color space.
If that's the case, though, we would need to change it, of course :-)
IOW RootLayer needs to have a list of drawing surfaces. Each surface
can have its own display driver and HW interface. IOW that's a screen,
right?
RootLayer would need to divide a redraw region into the areas occupied
by different screens, and pass the display driver to the Layer::Draw()
functions (the fDriver member would need to disappear).
> Axel, IMO, what remains to be agreed on is the
> Workspace/Screen/RootLayer stuff. Expecting your response on what
> I've
> said above.
I'd guess we're almost there :-)
> 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
> ?
> Didn't we agreed at one time, region rebuilding should be done in one
> thread only, RootLayer's one?
That was not the topic here. The "problem" was that the communication
with RootLayer is very expensive. A lot more expensive than needed.
1) you malloc() a buffer for every little message, something the
PortLink architecture should prevent initially
2) you even use the port mechanism to exchange the messages - but the
communication is always done in a single team, so it could easily be
done with a real queue.
IOW it would be nicer to replace the PortLink with something else,
maybe it could even subclass the ServerLink class, but perhaps this
would be more complicated than needed (OTOH that class could be made
fit with a little refactoring, too).
> 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.
That's perfectly okay - it's also not always as "exciting" as it was
yesterday ;-)
And yes, it's at that time, so if you can't sleep for whatever reason,
you're welcome :)
Bye,
Axel.
Other related posts:
