Zoom button bugs

The window shows an outline pane plus two panes of text. It is two-thirds the height and width of a 24" monitor, with the text panes roughly similar in size. Clicking on the zoom button should expand it to full screen but instead it shrinks it to the size of A4 paper. In this state both panes of text are narrow. Clicking on it again should restore it to its previous state but it does not size the panes correctly. Instead of enlarging both panes of text, it enlarges only one of them.

Scrivener 1.5.1, OS 10.5.7, Intel.


This is not a bug - far from it. In fact, it is a feature, and a useful one (as explained in the Tutorial project, which I recommend going through). Unlike in Windows where you have a “maximize” button that fills the screen with the window, on OS X the zoom button is not designed to work like that. Rather, it is designed to optimise the work space so that the window fits the contents perfectly. You can see this behaviour in Pages, Safari, and many more well-designed apps.

In Scrivener, the zoom button resizes the window so that its height fills the screen, but the width perfectly fits the binder and inspector as-is and the editor to be the default width as set in the preferences. Go to Preferences > General to set the editor width to something wider. On a 24" screen you will want the default width to be wider than the default setting, which is more suitable for smaller screens.

Note that if you set the default editor width to 0 or something stupidly large, then the window will resize to fit the entire screen as you desire. However, for that there is also the “Zoom to Fit Screen” feature in the Window menu (ctrl-cmd-=), so that you can have the best of both worlds. (Generally on a wide screen it would not be desirable to fill the entire screen with the window anyway, as the text area could become unbearably wide.)

All the best,

How about one feature and one bug? I take your point about the overall width but surely the size of the panes ought to be remembered and restored along with the size of the window.

I agree; the Binder getting crunched down is a bit of a hassle. Though, if you find yourself changing window sizes a lot, you might try having a look at the layouts dialogue. Using that you can set up “sessions” which save the entire window state including its size and what is turned off or on within it. Then in the future you can just double-click to change the application for one purpose or another. I have, for example, one that takes up the entire screen width that is just Binder - Split A - Split B, in three columns; then another that looks like TextEdit. No header/footer/binder/inspector. Just a text window; another that is standard Binder-Editor-Inspector; and so on.

I don’t agree; I don’t really know what you mean; binder size and inspector size stay constant; only editor width defines the new size. And as I say, zoom to fit window is available…
All the best,

Now that I think about it, what I was referring to was bring up the Inspector on a window with a non-minimum Binder width; so different feature/area of window management. I just presumed that was what the OP was talking about since, as you put, the zoom feature never touches left or right pane widths—unless they have some weird case I’ve never seen.

What I have seen in this regard: Set a window with Binder-Editor layout, and then shrink both down as small as they will possibly go. Now open in the Inspector; Scrivener will expand the width of the window the number of pixels necessary to accommodate the Inspector width + the minimum widths of the other two splits.

Now without changing anything, turn the Inspector off again, and increase the width of the Binder to something generous like 3/5 of the window width (about as far as it will go for me). According to the above behaviour, if you now open the Inspector, you should expect the window to widen itself again slightly to accommodate the Inspector width + the widths of the other two splits. Instead, the Binder contracts back down to minimum, and when Inspector is turned off again, it stays that way.

This demonstrates the most dramatic case, but in much smaller degrees this happens a lot whenever you are working with a window size that is not massively buffered with extra space. Generally the Binder size floats around at 10 to 15 pixel amounts; and this is rather annoying when you’ve set it to be a certain width for a good reason.

Honestly, finding a resizing flow that would work perfectly in all situations is very difficult; no matter what situation you posit, there will always be one where the zoom cannot second-guess it. I think the current way it works is good for the majority of situations, but it will never entirely replace having to adjust things yourself for a perfect workspace… Or I could just go insane trying to make everyone happy. :slight_smile:

All the best,