[BUG] Preview pane shrinks with toggling visibility
Completed
The preview pane shrinks every time its visibility is toggled, until reaching a minimum width. From a fresh start (wiped preferences, new Folder):
1. The Preview pane should be visible at first, but if not reveal it with `⌃⌘P`.
2. Using the resize handle, drag its width out to around halfway.
3. Now just repeatedly press `⌃⌘P` and you should be able to watch the preview column shrink with each repetition.
nvUltra: Version 1.0.0 (20)
macOS: 10.14.4 / Dark Mode / Retina (12")
-
How wide is the window you are using before toggling the preview back on?
Is the file list visible when you toggle the preview back on?
I generally use half-width windows (e.g. either a left and right window, or 4 windows that each take up a quarter of the screen.) On my non-retina 1080p display, I never any issues. On my retina MacBook Air, with the file list visible, what I see is that the window gets bigger in order to allow the preview to toggle back on; unless I am at full resolution.
That said, I don't see the preview getting smaller, but instead the window getting bigger.
Can you send screenshots?
Do you have any apps/extensions that manage window sizes enabled?
0 -
Ah, try turning "Animate layout changes" off, in the General tab. Even though I had reset preference, the notorious old macOS .plist cache index bug must have bit me. So here is the *full* list:
1. Quit nvUltra.
2. On shell:
```
$ rm ~/Library/Preferences/com.multimarkdown.nvUltra.plist
$ killall -u $USER cfprefsd
```
3. Launch nvUltra; `⌘W` to close slideshow.
4. Create a new test folder wherever you wish. Don't touch window size or placement.
5. Disable **Animate layout changes** in General preferences.
6. Hit `⌃⌘P` and slide the preview width area as far as it will go to the left (shoving the sidebar down to minimum width as well).
7. Now just toggle the preview pane.
Hopefully that does it!
0 -
I can replicate, thanks.
Not sure why turning off/on animation affects this, as otherwise the steps in the code are the same. Maybe behind the scenes the animation causes a slight change in the order of the steps. I'll have to dig into that further.
0 -
I could not figure out what exactly the problem was.
So I figured out something that was either really clever, or a real hack that will come back to bite me.... ;)
Turning off animation is basically the same as animating with a really short duration. So instead of animating over 0.3 seconds, when animations are disabled it animates over 0.01 seconds. So it looks like animations are off, but the width preservation functions like animations are on, which works properly in my testing.
Can reexamine if further issues arrive.
Thanks again!
F-
0 -
I’m getting around to testing this, and so far it is looking stable. I did notice a quirk though—not sure if is related to this fix or general adjustments that weren’t in the change notes. First try with the same checklist as above, only stop at step 6.
The result we get is that the window expands to accommodate the width of the preview pane, but when we turn it back off, the window does not contract. So we end up with a text editor that is far wider than desired (presumably) and having to manually resize it back down every time Preview is opened and closed.
What is confusing to me about the behaviour is that the expansion appears unnecessary in some cases. I can surely understand the window width being expanded if it is too narrow to fit the File List, Editor and Preview all at once—that much is necessary. However if the window is already at that state, it still seems to expand. Here is a way of testing that:
- Set up your test window so that all three splits are shown.
- Decrease the width of the window down to its absolute minimum.
- Toggle the Preview pane off and back on.
By the way: See also.
0 -
This seems to be related to a subtle issue in NSSplitViewController, and the way it calculates necessary sizes. Perhaps it has to do with the exact order of steps internally (e.g. expand the preview, oh -- now things are too small so make window bigger, now I can adjust the editor size to make it smaller, oh! because the window is bigger I don't need to make the editor smaller, great!)
As far as I can tell, this only happens if the window is very small (in my opinion too small to actually be used for much, especially if all three panes are visible).
(Historical context...)
Years ago, Apple's NSSplitView was pretty much garbage, from what I could tell. Everyone and their brother seemed to have a custom subclass that added behavior that should have been default. The ones I tried were either unnecessary complex, or didn't do what I needed. For Composer, I created my own view subclass that handled general layout demands (like Apple's subsequent NSStackView), toggling views off/on (like the info bar (word count, etc.)), and also allowed dragging to resize (adding NSSplitView functionality that actually worked). This allowed me better control, and things generally worked the way I wanted. (Bonus -- it was compatible with iOS, with the exception that you couldn't use your finger to drag the divider).
More recently, I wanted to go back towards using built-in Apple components if possible, and NSSplitViewController is available. It is *much* better than the old NSSplitView, and *almost* allows everything I needed.
The one thing it doesn't seem to do so well on (out of the box), is a good job of treating subviews proportionally. For example, if I set the preview width to equal the editor width, and then toggle it off, then make my window much bigger, and then toggle it on -- I still want the two views to be equal (e.g. 50% each). NSSplitViewController handles this well while dragging when everything is visible, but not when you can collapse the preview and re-expand it later. This required custom behavior.
I've tried a bunch of ways of handling this, and the current behavior is the best. There may be a better way of handling it, and I may figure it out. Or there may be a bug in Apple's code that gets fixed. Or they may add default functionality that allows me to get rid of custom code. Any of these would be great.
But in the meantime, I think I have hit the point of diminishing returns on this.
I agree that the behavior in the example you cite is not what I would expect. However, I can't imagine that circumstance actually coming up in "real life" -- That requires a text editor width of 200 pixels (enough for one or two words per line, depending on margins), and a preview of 200 pixels (also enough for one or two words per line), and a file list width of 150 px (enough for short file names only). While nvUltra does allow you to shrink the window that small, it is certainly not recommended. And the fact that it tries to encourage you to use a slightly less unrealistically small window is probably a good thing...
Just had a thought -- I noticed that when the window was even smaller, the info bar was truncated. After nvUltra resized, it was fully visible. It *may* be that nvUltra is resizing the editor pane so that it can accommodate the full width of the info bar? So even though the width is allowed (e.g. >= 200 pixels), it would "rather" be wider to allow the info bar to display? I'll try to play around with this as I get the chance.
0 -
As far as I can tell, this only happens if the window is very small (in my opinion too small to actually be used for much, especially if all three panes are visible).
To clarify, I first came across this with what I would consider to be a reasonable window width (50% of MacBook 12" screen). The simple minimum-width test I provided above may have been a red herring, it just looked like the easiest way to reproduce it. I think it requires a fresh session to reproduce, it comes and goes. Try this (with vanilla settings):
- Slide the window all the way over to the left side of the screen.
- Resize with the mouse so that it fills about 50% of the left side of the screen.
- Close the file list so that all we have is an editor (may or may not be necessary, but I think it is better to demonstrate with no potential minimum width issues).
- Open a note or create on as necessary.
- Hit
⌃⌘P.
What I get at this point is the preview sliding out from the window, until it consumes about 75% of the screen. If I toggle it off, then window of course stays that wide and I have to resize it again. From that point on the preview pane appears to cut into the editor as expected.
Hopefully that helps you track it down.
Regarding NSSplitView—I only know of the horrors second hand (and spending far too many hours helping to debug its messes), but “garbage” is about right!
0 -
What's the resolution on your display?
0 -
Funny, I was just thinking about that a moment ago, how it might be hard to get things the right size on a different display. Apple doesn't tell you want the resolution is on Retina screens, but it says "Looks like 1440 x 900" in the Display prefence pane.
Would any of the key-value pairs in the preferences .plist be of use in getting the stored window size? Well, it's probably around 450pts. I see a few values in arrays here that look quite close to that. But it wouldn't surprise me if the trigger is somewhat dependent on overall display size too. Either that it or is a coincidence that even a few pixels to the right of 50% fails to trigger it.
0
Please sign in to leave a comment.
Comments
9 comments