[haiku-development] Re: Zoom sucks and what to do about it
- From: Adrien Destugues <pulkomandy@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sat, 31 Jan 2015 09:39:23 +0100
On Fri, Jan 30, 2015 at 08:21:53PM -0500, John Scipione wrote:
> >On this ticket you got comments from 3 other developers saying that it
> >was useless. How much more do you need?
>
> I'll admit that I don't personally desire zoom on About System either.
> However, I would like to support an environment that fosters the ideas of
> newcomers. Closing a bug as invalid after less than a day with little or no
> regard to the thoughts of the bug reporter comes off as callous and is
> unproductive to the goal of creating the best operating system possible. In
> this case we have probably scared away a potential developer.
He is still around on the IRC channel and asked for information on other
bugs, so I think you are wrong.
Part of our development workflow is discussing changes (especially in
the behavior of the UI) on this mailing list, because as you know there
are always strong opinions on this matter. New developer should also
learn that: in Haiku, not all patches are welcome, and to get commit
access to the project it is not enough to write code. The main
requirement is "sharing the vision of Haiku" (however vague that is).
>
> >Tracker is an example that implements what I consider the correct
> >behavior: the Zoom button should size the window just big enough to make
> >its contents visible. There is no need to make the window use the whole
> >display or nearly the whole display area if it doesn't need it.
>
> Each app should zoom a bit differently based on its needs. The zoom behavior
> on Tracker is one example, and a good one, we need a few more. For example
> WebPositive could zoom to fit the contents of the webpage.
This has been on the TODO list for Web+ since the 2009 GSoC project at
least. However it is not always easy to know what the size of the
contents of a webpage is.
>
> >In the case of AboutSystem, the default window size is already a sane
> >and appropriate one. You could make the window higher or wider, but it
> >wastes space without a big improvement on its usability. This is why I
> >think having a zoom button there is useless.
>
> Okay fine, I don't want to dwell on the About System window when the issue
> here is much greater.
Sure. I just think examples of windows that have no zoom button at all
are as important as others. It is just a different example of zooming
behavior, and is as valid as zoom-to-contents.
>
> >I would prefer if the zoom button did not do that. With the deskbar on
> >the side as it is by default, and the tabbed decorators, it's fine to
> >have a maximized window. The deskbar will still be reachable in the hole
> >left by the tab on its right side. This allows "fullscreen" windows and
> >doesn't really make the Deskbar unreachable, so not much is lost (ok,
> >you can't see the clock anymore).
>
> Firstly, you should not assume that Deskbar is located in the default top
> left position, secondly, zooming on top of Deskbar is unnecessary and
> frustrating most of the time because it covers Deskbar so you can't access
> your apps for little gain. Thirdly, the Haiku user community has voiced
> their opinion on the matter loudly and often in the forums, they don't agree
> with you, they want the Deskbar to remain uncovered. Forthly, nothing
> prevents us from covering Deskbar in the cases that it makes sense to, right
> now we cover Deskbar out of laziness, not design.
I think the problem is in another place. The fact that the default
behavior is to maximize the window means that it ends up covering the
whole screen, including the deskbar (or parts of it, depending on how
the deskar is positionned).
I would be ok with a change that doesn't alter my workflow, and matches
how it works (or worked?) on Windows. If the Deskbar is set to "always
on top", then maximized windows should not zoom above or under it. If it
is not, the current behavior should be preserved.
However, the current behavior is annoying only as long as windows are
maximizing, if they were using fit-to-contents instead, the windows
would be much smaller and this would already avoid any problem here.
> >Zooming usually does not change the window position, unless it makes the
> >window fullscreen (which I think it shouldn't). So I don't see how
> >zooming can put the app fully offscreen.
>
> Imagine you have a tiny StyledEdit window in the bottom right corner of the
> screen and you push the zoom button, what should happen?
As I tried to explain, I can think of 3 choices:
- Resize the window to the fit-to-contents size, then move it towards
the screen center so its bottom-right edge is at the screen
bottom-right. This has the annoying effect that the zoom button you
are clicking moves away from under the mouse, and that the window is
moved elsewhere.
- Resize the window so it fits the content as well as possible, but clip
it to the screen edges. This way the window isn't going offscreen, but
it is also not resized to the appropriate size. So you need to move
the window closer to the screen center, and click the zoom button
again.
- Resize the window to its fit-to-contents size, and do not move it. The
window is partially offscreen, but can be moved at a more approriate
place manually. It does not need any further resizing.
I prefer the 3rd solution for these reasons (it just resizes the window
and does not try to be smarter than that). It leaves some open
questions, such as what should happen if the fit-to-contents size is
bigger than the screen size. Maybe in that case we should maximize the
window on the relevant axis (so a tall window would move to the screen
top, but not move horizontally, and still get its correct horizontal
size). Maybe this needs some more experimentation to see how it feels.
--
Adrien.
Other related posts:
