Axel Dörfler wrote:
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?
I was talking about 2 lists holding all application and windows pointers much like it's done in Desktop::fWinBorderList now for windows, so that the window manager would know which windows are present at one moment. But, I think I was thinking wrong as there will be a window manager for every Desktop object.
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).
I don't see the difference from what I proposed. You use a list of physical screens, I use an object which maintains a list of physical screens. I like my approach better because the driver which will draw half a window on one screen, half in another will use the Screen derived class instead of a Workspace object. I want things to be clear, and for that reason I think using a list inside Workspace would complicate things and introduce code dependences.
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.
Hmm... I will test this! :-)
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.
Yes, taken from the current workspace.
Each surface can have its own display driver and HW interface. IOW that's a screen, right?
Yes, yes, yes... Finally, we understand each other! :-) Are we? :-)
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).
Yes!! :-) That's what I was talking about.
However, things are a bit strange. They need to be cleared out.
For example(the simplest): if a Layer is shown half on a screen,
half on another. We can't simply call ::Draw(rect, Driver()), because of
what I understood from above the driver would point to a particular HW
interface(screen) and only half of that Layer would be drawn.
Also, calling Draw(rect_clipped_to_screenX, Driver(X)) for every
screen onto which this Layer appears is not an option because it's just not
... right(would break the programming model).
So, we need to do something else.
And here I think you don't agree with me. :-) That Layer only "sees"
a region in which it can draw. the drawing that it does must be decomposed
for the 2 HW interfaces onto which this Layer appears. That would need a
VirtualHWInterface and a VirtualScreen. :-)
If you don't agree, OK, give another solution.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 :-)
A little bit more... :-)
That was not the topic here.
OK, we'll talk another time about this.
bye, Adi.
