Opened 7 years ago

Last modified 5 years ago

#8665 new enhancement

Zoom button behavior improvements

Reported by: mmadia Owned by: stippi
Priority: normal Milestone: R1
Component: User Interface Version: R1/Development
Keywords: Cc:
Blocked By: #5588, #8659, #8666, #8667, #8668, #8669, #8670, #8671, #8673, #8674, #8676, #8677, #8678 Blocking:
Has a Patch: no Platform: All

Description (last modified by 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.

Change History (21)

comment:1 by mmadia, 7 years ago

Blocking: 8666 added

comment:2 by mmadia, 7 years ago

Blocking: 8667 added

comment:3 by mmadia, 7 years ago

Blocking: 8668 added

comment:4 by mmadia, 7 years ago

Blocking: 8669 added

comment:5 by mmadia, 7 years ago

Blocking: 8670 added

comment:6 by mmadia, 7 years ago

Blocking: 8671 added

comment:7 by mmadia, 7 years ago

Blocking: 8673 added

comment:8 by mmadia, 7 years ago

Description: modified (diff)

comment:9 by mmadia, 7 years ago

Blocked By: 8659 added

comment:10 by mmadia, 7 years ago

Blocked By: 8666, 8667, 8668, 8669, 8670, 8671, 8673 added
Blocking: 8666, 8667, 8668, 8669, 8670, 8671, 8673 removed

comment:11 by mmadia, 7 years ago

Blocked By: 8674 added

comment:12 by mmadia, 7 years ago

Blocked By: 8676 added

comment:13 by mmadia, 7 years ago

Blocked By: 8677 added

comment:14 by mmadia, 7 years ago

Blocked By: 8678 added

comment:15 by leavengood, 7 years ago

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.

comment:16 by leavengood, 7 years ago

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.

comment:17 by mmadia, 7 years ago

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.

in reply to:  16 comment:18 by anevilyak, 7 years ago

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.

Last edited 7 years ago by anevilyak (previous) (diff)

in reply to:  14 comment:19 by humdinger, 7 years ago

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.

comment:20 by mmadia, 7 years ago

Blocked By: 5588 added

comment:21 by diver, 5 years ago

Component: - GeneralUser Interface
Owner: changed from nobody to stippi
Note: See TracTickets for help on using tickets.