Zoom button behavior improvements

[mmadia]

This is a meta-ticket, based on the ​Programming with S&T mailing list thread from June-2011

One of Haiku's attractive features is the consistency and cohesiveness of the system as a whole, including the GUI. There are a few instances where the zoom button is less than consistent (or rather, its per-application use is less than ideal).

Currently, three possible behaviors can be seen and alternate between the current dimensions and one of:

1. "best fit in minimal space" (Tracker, Mail)
2. maximized window, allowing Deskbar's menu button to be viewable (Terminal, StyledEdit, Pe)
3. full screen, no window decor nor Deskbar viewable (Web+, ShowImage, MediaPlayer)
4. remove GUI elements (Magnify, PoorMan)

The purpose of this button is to be able to switch between two meaningful window sizes. What exactly this is, is completely up to the application, and hence the different behaviour in different apps.

To note, toggling full screen is normally done with CMD+Enter. Double-clicking the content area (ShowImage, MediaPlayer) and F11 (WebPositive) are also used in some instances.

[leavengood]

I think in many cases, becoming maximized on the Zoom button makes sense. In fact I already have it on my TODO list to make WebPositive do that instead of going full screen. If we switch all the apps to be "best fit" when the zoom is hit, then I thnk we need some other system way to get a maximized window. I personally would like to see the Windows "drag to top" maximize and "drag to side" for half screen, which have also been copied in GNOME and in some Mac utilities. If we add that, I would be OK with changing the zoom to always be best fit. Otherwise we are back to manually resizing for people who want maximized Windows, which includes me in many cases. And that kind of sucks.

[leavengood]

BTW, if we do make all these apps do best fit, this sounds like something which could become either part of the shared kit or maybe even the API, like CenterOnScreen, which I added. I guess it could take a pointer to a scrollview and use that to calculate the window size to make the scrollbars disappear, then resize the window to that, maybe with an optional screen centering too. ResizeToBestFit I guess.

[mmadia]

Right, I'm not suggest a best-fit strategy for all apps, just more of them.

When one considers that wide screen monitors are becoming more common place, a maximised application makes less sense as a meaningful window size.

[anevilyak]

Replying to leavengood:

BTW, if we do make all these apps do best fit, this sounds like something which could become either part of the shared kit or maybe even the API, like CenterOnScreen, which I added. I guess it could take a pointer to a scrollview and use that to calculate the window size to make the scrollbars disappear, then resize the window to that, maybe with an optional screen centering too. ResizeToBestFit I guess.

That's not necessarily sufficient, the window might need to resize some internal elements (i.e. column widths in a column list view) in order to be able to reach its ideal size, which scrollbar constraints alone wouldn't tell you.

Edit: Furthermore, in, for instance, a Window using split views, a single scroll view alone wouldn't be sufficient information. I don't think there's really a good way to do a shared implementation of this since there are simply too many corner cases that require a) extensive knowledge of the window's UI elements, and b) knowledge of the fact that a zoom is specifically what's being asked for, rather than any other type of window resize, otherwise you'll invoke inadvertent side effects like breaking a user's adjustments to their window splits or whatnot.

[humdinger]

Can't find an example right now, but the "zoom" (actually sometimes called "alternative-size", I think) button isn't necessarily only a two-state toggler. The first click can do a best-fit, the second (or if it's already best-fitting) could do another alternative size, e.g. maximize. Another click could then go to the last saved user-chosen size.

Personally, I'd rather have an "intelligent" button (depending on the wits of an app's dev) and an easy way to resize-to-fit or some other useful size, than a totally predictable (always maximizing) button that often don't make sense.