[haiku] Re: Full-screen and multi-monitor handling, related: I haven't used Haiku, but from what i have seen, this is my atempt to make Haiku R2 compitable to other OSs when released

  • From: André Braga <meianoite@xxxxxxxxx>
  • To: "haiku@xxxxxxxxxxxxx" <haiku@xxxxxxxxxxxxx>
  • Date: Sat, 20 Dec 2008 07:50:50 -0200

Em 20/12/2008, às 02:04, "Cyan" <cyanh256@xxxxxxxxxxxx> escreveu:

Fair enough. The reason I suggested only illegal areas is because
that seems to be the only one that's absolutely essential; legal
areas alone wouldn't be enough.
I believe you're having a different interpretation of what legal areas would be than mine :)
Legal areas are not different than full area minus illegal areas, sliced on the boundaries of said areas, and picking up the largest resulting areas (at least those are the ones that we're interested in; the others (narrow strips) could be discarded).
Conversely, illegal areas are the same as subtracting the union of all legal areas from the full area. 

I'll illustrate this using your example below.


For example, the case with two monitors side-by-side (1280x1024
resolution each), deskbar in the top right corner, the illegal
rectangle case would look like this:

1) Top=0, left=1280, width=0, height=1024
2) Top=0, left=2448, width=112, height=156


Ok.


With legal rectangles only, I suppose it'd look like this:

1) Top=0, left=0, width=1280, height=1024


Ok.


2) Top=0, left=1280, width=2448, height=156
No, no. That would be 0, 1280, 1168, 1024 (full height; width limited by illegal area boundary). 


3) Top=156, left=1280, width=2560, height=868


And that would be 156, 1280, 1280, 868 (full width; height limited).


The problem now is that while expanding a window works as expected
on the left-hand monitor, on the right-hand monitor the window
will never cross the boundaries between rectangles #2 and #3
(which is about 1/6th of the way down the screen).
Because your definition forbids that the legal areas overlap. Mine basically mandates it :) 


But it shouldn't be a problem to provide both, perhaps by a separate
function call. The only difficulty would be calculating the number of
rectangles created when there are several illegal areas on the screen
(e.g., deskbar instances in each corner of a very large monitor).
Not at all, just take the largest slices, begin-of-legal-area to begin- of-illegal-area on each axis, repeating for each edge shared between a legal and an illegal area, and allow them to overlap.
(I really hope this makes any sense. I'm writing this on my mobile, so I can't draw some useful ascii-art diagrams to better explain what I meant. But I could, later today, if necessary.) 


But as you say, I suppose that's best to put in the OS anyway rather
than have each app re-implement it if required.
Definitely. Providing the bare minimum does not a good API make. Not since the X-Windows toolkit :P 


Absolutely; that's why returning a variable-sized list of
rectangles would be better than some kind of modification to
app_server to make it handle the Deskbar as a special-case. The
areas may need to change dynamically too, in the case of moving
the Deskbar around, having it auto-hide, etc. I'm not sure if this
creates any additional complications -- on the face of it, it seems
like simply re-clipping all the windows to the new rectangle
(using the algorithm below) would be sufficient?
Resizing windows automatically based on some external event like moving the Deskbar violates the POLA (but see the parenthesis below). The automatic snapping should only occur as a response to user- initiated zooming. That's what I meant by potentially changing the semantics of the zoom button. First click fits to viewable content, second click snaps to largest area the window can resize itself to, third click restores to initial state. Actually it's not really a change of semantics, but more like combining the best of both worlds: the maximisation semantics and zoom to fit document semantics. 


As for the actual algorithm to move and resize windows to make them
fit, I imagine it would have a similar effect to this pseudo-code:
As mentioned above, I'm using my mobile to write this, so I won't even pretend I read your algorithm since I wouldn't be able to make heads or tails out of it ATM, but I will take a look at it later today. 


Hmm, are we? I was thinking more along the lines of leaving the
zoom button's function mostly unchanged (expanding the window to
best fit the document), but simply performing additional clipping
to ensure it doesn't traverse any illegal boundaries on the left
or bottom in the process.
At least, that's how I generally use the zoom button, but other
people might have different expectations?
Yes, they do; augmenting it with maximisation semantics would solve the main gripe that users switching from Windows and KDE/Gnome have with Mac OS and BeOS, with no downsides other than requiring an extra click to reset the window to its first state. I have grown used to it already, but people are often surprised by the lack of a maximise button. 


Tracker is a good example: hitting the zoom button will expand the
window horizontally to fit all the columns on-screen but no larger,
and vertically it will expand to fit the entire list of files in
the window (unless it hits the bottom of the desktop first).
Precisely the behaviour I meant when I suggested flags for expanding to max available height, width, or both. 


With clipping in place, it would do the same thing, except when
the Deskbar is at the bottom, it would stop just short of the
Deskbar instead of overlapping it (assuming there are enough files
in the window to make it reach the Deskbar).


Correct.


True; there'd surely need to be some way of choosing priority between
horizontal and vertical for the function that expands to maximum
size. It could be more of a case of allowing the programmer to
override the default feature though, to save each app from
re-implementing those few lines of code (and in some cases
forgetting it completely, and letting users who care about overlaps
pay the price).
Right; but users should never have to pay this price. This algorithm should only kick in for events that result in automatic window placement, like a new window being spawned or the zoom button being activated on an existing one. Under no circumnstances it shall kick in as a result of explicit window placement or resizing done by the user. The only acceptable automated *aid* in this situation is an edge snapping algorithm like those found on several X11 desktop environments.
(I'm still not sure what would the POLA-friendly behaviour of moving a window to a screen with smaller legal areas than the window currently occupies be. Or any other action that modify the available areas, actually. But auto-resizing a window after the user simply moves it somewhere would certainly raise eyebrows... X11 DEs solve this by having alt+drag move the window no matter where it was clicked to initiate the move (and then the user can move the window around until the proper control is made visible, and following that, resize the window by hand or hit a maximise/zoom button), but we have nothing like this on app_server.) 


I don't recall what the consensus on multi-monitor support was,
but as a multi-monitor user myself, there would be some quite severe
changes necessary to do it this way!


Uh... Pretend I never said "workspaces", then.
s/workspaces/BScreen/g, or whichever entity maps a portion of the desktop to a given monitor.
(Sometimes my mind has a mind of its own ;) One of the more colourful consequences of suffering from ADHD on adulthood, I guess.)
The rationale still holds, though: legal/illegal areas should be bound to said containing entity; BScreens if I got François' remarks right. 


Anyway, thanks for the feedback André; as you can see you've got me
pondering quite a few things. =P
You're more than welcome; I should be the one thanking you for further elaborating and refining your ideas based on my not too clear remarks :) 

So, thanks!


Cheers,
A.

Other related posts:

  1. Home
  2. haiku
  3. Archive
  4. 12-2008