for this; I can only recommend this one to everybody :-)
OK then, I'll use qemu.
You are going to take care of multiple monitor issue along with mapping VirtualScreens to Workspaces? RootLayer locking through MultiLocker, maybe? What else?
Also the RootLayer/Desktop/ServerWindow/Input Handling separation. My original proposal was:
In the ongoing discussion after that, it was vastly improved, though :- )
:-) Yeah. I hope we understood each other, as I remember the talk was not that... clear, if I might say so. :-)
I found a problem in the way we scroll views. ATM, we scroll views
by modifying a view's origin. I think this is not correct. We should change
the bounds rectangle only, and not touch the view's origin. (Also, modifying
a view origin, will modify a view's bounds rectangle accordingly, otherwise,
there would an "autoscroll" action why I don't think we want.)
I don't think you're right here (at least if I understand you correctly) - why should the view's bounds are changed when you scroll the view? That can't really work.
In case you are confused by the BScrollView class: that's only a helper, you can scroll a single view alone without any other views - and you certainly don't want to move the view around in that case, just its contents.
Wait a second. I think there is a big communication issue here. Or, misunderstanding of bounds/scrolling/local_coordinates.
I'll explain what I understand.
You have the frame rectangle which I see as the size of a view (described in parent coords). You have a local coordinate system with a local origin. You have a "view(window) area; (maybe the term viewport is better?)" which is exactly the size of the view but it's in local coordinates and by default has its left top corner at the origin of the local coordinate system. Scrolling a view means: modify the bounds rectangle(NOT its size) so that it "points" to another area of the local coordinate system. It's merely an OffsetTo(x,y). Local coord system's origin is NOT modified. Modifying the local coordinate system's origin, is a completely different thing than the bounds rectangle of a view. However they _must_ be related, because you don't see a view scrolling automatically to a new position because its bounds rectangle did not change. That's why I think when setting a local origin the bounds rectangle must be modified(relocated) so that it points to the same area as it did before the origin was set.
It's clearer now?
Sure, that would be nice.OK then. Also, I will try to make the changes I spoke about 2 weeks ago: MarkDirty(reg);, MarkDirty(reg); MarkDirty(reg); ... TriggerRedraw(rebuild=true); (false - just redraw. no visible reg recalculation)
Okay, I'll first have a look at this font crashing bug.
Do we have such a bug? :-)