[haiku] 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: "Cyan" <cyanh256@xxxxxxxxxxxx>
  • To: haiku@xxxxxxxxxxxxx
  • Date: Fri, 19 Dec 2008 18:08:36 GMT

"Andrew McCall" <andrew.mccall@xxxxxxxxx> wrote:

> I have *always* had a major problem with the deskbar ever since the
> very early days of BeOS.  If you are using an applicaiton and
> maximize it to full screen, it covers the deskbar, meaning it
> requires more clicks to complete a process than it would on OSX/
> Gnome/KDE/Windows.

"Ritrup Biswas" <ritrup@xxxxxxxxx> wrote:

> The problem most people face is- when a window is full screen, it
> is time consuming to go back to other windows behind it.


The send-to-back function goes some way towards helping this, but
the main issue is that the BeOS GUI was never really designed to
encourage full-screen use of applications. The "zoom" control on the
window, in most applications, simply resizes the window to best fit
the displayed content, not bring it up to full screen.

I actually really like this behaviour. Full-screening applications
seems to me like a hangover from the 1980s, when single-tasking
and task-switching were the norm. I never use that functionality
these days, even on the rare occasions when I use Windows. It was
quite good back in the days of 12" monitors, but with 30-40" monitors
and multi-monitor setups slowly becoming the norm for desktop
installations, maximizing an application to full-screen or full-
desktop is a huge waste of desktop space, and introduces problems
(switching between apps).

It's also helpful to encourage running applications in compact
windows from a design perspective -- a lot of Windows applications
seem to be designed with the idea that the user will just maximize
the application if they need a usable amount of work space.
Under BeOS or Haiku, you can't really make any assumptions about how
large the user will want the window to be, so you need to design it
as compact as possible, with the option of revealing more as the
window is expanded (e.g., how BeOS R5's scrollbars gain the extra
controls when the window becomes large enough).
That kind of design philosophy makes BeOS and Haiku apps potentially
more usable with very low desktop resolutions (portable devices),
as well as high resolutions with multiple apps open.


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.

In the case of a single-monitor 800x480 desktop, with the Deskbar
in the top right of the screen, one rectangle will be returned which
is the size and position of the Deskbar (top=0, left=688,
width=112, height=156).

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).

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.


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.

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.

Total desktop size is 3840x2400. The list of illegal
rectangles is:

1) top=0, left=1920, width=1920, height=1200
2) top=1200, left=1920, width=0, height=1200
3) top=1200, left=3728, width=112, height=156

The first rectangle marks the entire area above the right-hand
monitor as illegal. This stops any windows appearing where they
cannot be seen (due to no monitor being mapped there).
Additionally, for the app_server a flag could be attached to this
rectangle to indicate it's a hard limit -- the mouse should be
prohibited from ever entering this area to ensure nothing disappears
in there.
Note that a window can still overlap into this area, just as a
window can overlap the bottom or right side of a single-monitor
desktop, but the tab will never disappear into it.

The second rectangle represents the boundary between the two
bottom monitors. It has a width of zero (hence why they're
width+height rectangles instead of BRects), because no actual
pixels are illegal -- only the gap in between them.
Because of this rectangle, no window will ever automatically appear
spanned between the two monitors unless the user specifically drags
it to overlap between the two.
If a "hard limit" flag is used, the flag should be clear (to allow
the mouse to cross the boundary).

The third rectangle represents the area of the deskbar. Again if
a hard limit flag is used, it should be clear (to allow the user
to interact with it).



Any thoughts or suggestions for improvements regarding this method?
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.

Other related posts:

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