[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
  • Date: Fri, 19 Dec 2008 19:21:05 -0200

On Fri, Dec 19, 2008 at 16:08, Cyan <cyanh256@xxxxxxxxxxxx> wrote:
> Any thoughts or suggestions for improvements regarding this method?

A couple, actually :)

> This might be one possible way to fix the full-screen problem for
> situations where full-screen is really required (especially netbooks
> and mobile phones where the typical desktop resolution is VGA):
> Have some kind of API function which returns a list of rectangles
> which should be considered "no-go" areas of the desktop.

IMO a list of legal rectangles would work much better. The programmer
is likely going to construct it anyway given the illegal areas, so
having the API to list legal areas is more valuable than having it
list only the illegal areas. Of course both could (and should) be
provided (since each illegal rectangle will create up to four legal
areas, and when you start combining them some math-wrestling -- read:
overhead -- is bound to happen).

In the case of cornered rectangles like the Deskbar, only two areas
will be created, but it probably makes sense to account for potential
other forbidden areas, like docks, launchers or other drawer-type
widgets (think Control Strip and the ability to turn Finder windows
into tabs on Mac OS 8.x/9). Making it robust to handle the arbitrary
case will of course handle the trivial case of cornered rectangles and
strips going along the entire length of the desktop and would pose no
overhead (except on the person writing said code, as there would be
some interesting math going on :))

> Whenever a window is first opened, or automatically expanded
> (zoom box or "full screen" menu option), the new size is checked
> against the list of rectangles and moved/cropped accordingly, to
> ensure it does not intersect with one of the rects. This could
> be rolled into a single API call which takes the desired window
> rectangle as an input, and returns the adjusted rectangle (or sets
> the window size directly).

Since we're potentiallty changing the semantics of the zoom button to
snap to the largest legal area (given some criteria of "largest"),
it's better to have arguments/flags to the API call indicating whether
to fit by height, by width or both, and return an error in case it's
not possible, rather than having the app_server decide the window size
behind the application's back. The programmer could then decide to try
again with different restrictions, fall back to a compact GUI mode, or
show scrollbars, upon his discretion.

> This doesn't really need to apply to dragging windows -- a window can
> still be dragged to overlap with an illegal area, because the user
> is in direct control. But for all automatic expansion and initial
> opening of windows, the cropping should be performed.

+1, but only after taking into consideration the reasoning above :)

> This method can also be used to support multiple monitors natively:
> return rectangles to represent boundaries between monitors, and
> areas of the desktop for which there is no corresponding monitor.

Now that's a -1, for violation of the POLA (Principle of Least
Astonishment). See below.

> For example, consider a system with three 16:10 monitors, arranged
> two across, and the third one stacked on top of the left monitor.
> The deskbar will be on the bottom right monitor, in the top-right
> corner.

Wasn't it decided that multiple monitor support would be accomplished
by mapping them to workspaces? We're only missing an toggle to hide
the Deskbar from monitors other than the one the user declares to be
the main one (and notice how this is important: the user might decide
to have the middle monitor to be the main one. Or perhaps the
rightmost one. Even the left one. Or the bottom one. It's really up to
the user to decide what suits his/her needs.)

Anyway. I really frown upon the idea of windows deciding for
themselves on what monitor they're supposed to spawn into. They should
only be spawned on the monitor they were launched from. I'm positive
you didn't mean to allow windows to move to other monitors upon
receiving a zoom notification, but that's exactly what a naïve
implementation of your idea would accomplish :P

So the list of legal/illegal rectangles should be provided per
workspace, if we map workspaces to monitors, and it should default to
the workspace that originated the launching/zoom action.

And then you have your point back in double. +2 :)

Again, just in case there is a REAL strong reason for the programmer
to examine all legal areas in all workspaces mapped to monitors, this
could be provided as an option.

> I was planning to implement something like this anyway as a stand-
> alone background application initially, as a quick-fix for more
> complex multi-monitor setups. If there are any better suggestions
> for how to solve the "illegal areas" problem (encompassing both
> Deskbar overlap and multi-monitor dead-space), I'll implement that
> instead.

Both making it per workspace and listing the legal areas solve the
problem of gaps for free, and perhaps more elegantly. :)


Cheers,
A.

Other related posts:

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