[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: "Jonas Sundström" <jonas@xxxxxxxxxxx>
  • To: haiku@xxxxxxxxxxxxx
  • Date: Mon, 22 Dec 2008 21:40:01 +0100 CET

"André Braga" <meianoite@xxxxxxxxx> wrote:
> On Sat, Dec 20, 2008 at 11:59, Jonas Sundström
> <jonas@xxxxxxxxxxx> wrote:
> > Are you guys maybe over-engineering this a little?
> 
> Why? Is it such a big telling sign when two 
> programmers sound like they're having a lot
> of fun discussing something? :D

hehe :)
 
 ...
> > If the objective was merely to have three-state
> > zoom, this should already be possible to do with
> > the current BWindow::Zoom() - which an application
> > is supposed to override and give application-
> > specific behaviour.
> 
> Again, having it system-wide would be preferable
> than having every program necessarily overriding 
> methods. This goes somewhat beyond customisation
> to reach the realm of fixing default annoyances.
> How good is an API if you have to "fix" it every time?

How often a method is overriden is not a good measure
of how broken the default behavior is, especially for
an API such as ours, but I think I get what you mean. :^)

 ...
> This is why the concept of frameworks were born:
> you only have to think about what your app has to
> offer, not how it's supposed to blend in to the
> hosting environment.

(As an aside, not having thought about how to blend in
is one of my pet peeves. Even lots of native BeOS software
fail at doing so.)

 ... 
> > It probably works the way it does by default
> > since the system can not know which window size
> > constitutes a perfect fit.
> 
> Hence the proposed API returning a list of 
> candidate fits. :)

If the user isn't happy with the app's first choice, 
will he be able to click again, for the next candidate fit?
 
> > (Maybe with the new layout kit the system might
> > be able to guess a perfect fit and provide a three-
> > state BWindow::Zoom() default implementation.)
> 
> Guessing is never a good idea. It's quite the 
> reason why people complain about Windows' 
> obtrusiveness. Bad guesses.

With a best-fit-capable layout kit it shouldn't have to guess.

1. The user can't know for certain how the window will resize. (Not 
with the current API, and, I think, not with your model.)

2. The application can't know exactly how the user would like the 
window to resize.

I believe in the end the user is left with adapting to his/her specific 
set of applications, learning how they zoom and adapting his/her 
behaviour. A simple system (e.g. always maximize) is usually easier to 
grasp, and adapt to. Your model seems more complex to me than the 
current behavior. So there's going to be -more- guessing from both the 
POV of the application and the POV of the user.
 
 ...
> Which means that pre-selecting sensible options
> and letting the application decide between them

By way of an overriden method? ;)

/Jonas.


Other related posts: