[haiku-development] Re: Zoom sucks and what to do about it
- From: Adrien Destugues <pulkomandy@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 30 Jan 2015 23:35:18 +0100
On Fri, Jan 30, 2015 at 04:51:42PM -0500, John Scipione wrote:
> Recently, a new developer sambuddhabasu1 asked if he could implement zoom on
> the About System window and so created bug report #11808 in order to serve
> as a platform for the feature. This bug report was then closed as being
> silly, and I have reopened it because IMHO it is not (completely) silly. The
> window is both movable and resizable so it makes sense for it to be zoomable
> as well.
On this ticket you got comments from 3 other developers saying that it
was useless. How much more do you need?
>
> Now, Haiku won't live or die based on whether or not the About System window
> is zoomable or not, however, the developer asked "if there were any examples
> or any existing app which implements [zoom] functions" and sadly the answer
> to my knowledge is no. Worse yet, implementing zoom appropriately is far
> from trivial. The applications that come with Haiku either use the default
> zooming behavior as implemented in BWindow or do not utilize zoom. This is a
> tragedy because it sets an example for third parties that zoom is
> unimportant; I would like to change this.
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.
You are right that many other applications bundled with Haiku do not do
this.
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.
>
> The zoom behavior set by BWindow is quite basic and should not be used by
> nearly any application, it is merely a sane default. Instead we should
> implement better zoom behaviors for our apps to serve as examples for third
> party developer. In short we should do a much better job than we are
> currently doing in regards to zoom.
>
> I have implemented zoom on Paladin, a third party app and so am keenly aware
> of the difficulties involved.
>
> Firstly, zoom should take into account the size and position of Deskbar.
> This can be done now using the BDeskbar API and I suggest we implement this
> on the windows of all first party apps that utilize zoom.
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).
Moreover, the behavior of the zoom button should not be "make it
fullscreen", it should be "make the window just the right size so its
content fits". Full-screen mode should be a separate feature and
actually full-screen (as in wonderprush or mediaplayer), not just a
maximized window. HIG about this: http://api.haiku-os.org/HIG/ch10s03.html
>
> Secondly, we should take into account the border width and tab size of the
> window. Unfortunately, there doesn't appear to be any public way to do this
> so we are going to have to provide one. I simply faked it on Paladin by
> measuring and hardcoding the values used by the default decorator. BWindow
> however does provides this information from the private
> BWindow::_GetDecoratorSize() method. This needs to be made public if we
> expect zoom to be implemented seriously by third party apps.
There is an API for this. You can see it used in Screenshot or the
notification server.
>
> Thirdly, apps should make sure to not position themselves off-screen and
> should resize themselves in such a way that the contents of their window are
> formatted nicely. This unfortunately takes quite a bit of code to implement
> (~50 lines or so) but can be done once and then copied from app to app or
> better yet put in a common location so that it can be reused.
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.
If you think of cases where the app ends up partially offscreen, I would
say that is fine. I find the alternatives (moving the window closer to
the screen center to make it fit, or clipping its right/bottom corner to
the screen edges) more annoying, as one moves the window title bar
elsewhere while you are clicking it, and the other makes the operation
worthless (you need to move the window and start again).
>
> What do you guys think, is implementing zoom sanely worth the effort or not?
> If so, I'd like to create a series of trac tickets requesting that zoom be
> implemented in each app, one ticket per app, then I'd like to start writing
> the code and enlisting others to help.
It's worth it, for apps where fit-to-contents makes sense. A text editor
for example should resize to 80 columns, not the width of the screen (or
it could use the width of the longest line in the opened document).
Another thing you forgot to mention is un-zooming: clicking the button
when the window is already at the best size should restore the previous
size. This also adds to the complexity, and we should make sure it's
easy to implement that correctly.
--
Adrien.
Other related posts:
