[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: Sat, 20 Dec 2008 17:37:51 -0200

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

> It may be that I haven't grasped the full contents
> of your discussion, but I believe that the BWindow
> Zoom code I posted shows that there's no need to
> change anything about the app_server to make Zoom
> not overlap Deskbar.

We're not saying it's impossible, only that some utility API to handle
this instead of having developers reimplement it every time would be
handy. And that it could be generalised to "forbidden" areas other
than the Deskbar.

> If people want to add other Deskbar-ish components
> and want other apps to not overlap these, there's
> scripting support in BWindow, which any application
> is free to use to tell another overlapping application
> not to do so. ("hey, don't cover me")

This sounds like doing distracting extra work that's prone to failure
or omission, boilerplate code, or both.

> Of course this probably wastes a little more CPU
> than the deeper solution you're working on.

It's not about CPU as much as it is about not wasting developer's
time; it's about doing sensible things automatically, and making
sophisticated things possible. The BeOS motto of sensible defaults, if
you will.

> 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? Good APIs are
supposed to free us from thinking how the app is supposed to interact
with the OS, and instead concentrating on how the app will work. 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.

> BWindows default two-state zoom behavior which is
> similar enough to Microsoft Windows's maximize,
> but clearly intended to be smarter than that.

You could argue that automatic gear is smarter than stick shift, but
there are people who prefer the latter. And you can't really argue
they don't know better: they're actually the connoisseurs as far as
sport cars go.

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

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

There is no One True Way of laying windows out. There will probably
never be, else we wouldn't have architects (in the construction
sense). But, sticking to this analogy, there are some rules of thumb,
like golden ratios, safety guidelines and such.

Which means that pre-selecting sensible options and letting the
application decide between them, on the other hand, is a good idea.
Again, the concept of frameworks comes to mind.

> If Haiku's own applications lead the way by implementing
> three-state zoom, and it was also mentioned in an
> interface guide for application developers, it should
> not be difficult to move in this direction.

If the OS itself provides it, there's no trail to blaze: everyone
automatically benefits from it, partially even, and those actually
interested benefit the most.

And it would solve my main grip against Mac OS and OSs using the
concept of a zoom button in general. It makes sense to *maximise* the
browser window, g'dammit :)


Cheers,
A.

Other related posts:

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