[SUGGESTION] Modified preview pane disclosure model
To preface the suggestion, this is something that has “bothered” me a little with Composer. I do sometimes like a preview pane, but I don’t like how I have to select an editor width that is designed to accommodate the potential for some day turning the preview split on. I prefer an editor that is only a little bit wider than it needs to be, which doesn’t work well when it gets cut in half by a preview pane.
Ultimately it has lead to me ignoring the preview pane feature by and large. Making use of a Marked window to the side, where preferred editor width is unimpeded by a separate application’s window, tends to work better for my preferences. The effect I achieve is much like I would get from the below: an additive auxiliary view to the right of my editor that I can hide and reveal as needed.
So to that end, what do you think of the following approach to how the Preview split works:
- In most cases, turning on the preview pane is an additive action, causing the window width to resize to its previous width + whatever width is necessary to display the preview.
- In most cases, turning off the preview pane is subtractive in the sense that the window width is resized down to the current width minus the amount of width the preview pane was using.
- There is one exception, when the window itself is wide enough that its total width + the preview sidebar would exceed the display width, then the window is effectively maximised and the editor width is reduced to make room for the preferred width of the preview pane.
- Conversely, when hiding the preview pane with a fully maximised window, it doesn’t reduce the width of the window but rather works more like it does now, toggling the preview pane on and off within the editor area (resizing it). This preserves what can be the presumed intention of the user to have a maximised window.
- The cumulative effect of this approach is that the sidebar appears to be appended to the window rather than an element within it that splits and cuts into the preferred editor area—potentially forcing the window wider permanently in order to do so.
I think this is a good model for a text editor because it puts a lot of emphasis on preserving the user’s text editor layout, which I think is a good goal to have in a program where one might be typing a fair bit.
-
To reply most effectively, I think I need to explain a bit of the bigger picture.
macOS unfortunately has limited window management support, unless one uses third party utilities to add additional features. (I have been using Optimal Layout, but have recently tried experimenting with Magnet since it was $0.99 on App Store and Optimal Layout, while now free, is no longer being maintained.)
I use these applications to more effectively take advantage of displays that are too big for a single window. I most often size windows such that they take either a quarter or a half of the real estate on a given monitor. For more complex windows (such as Xcode), I use the whole monitor most of the time. I will often have setups such that one document takes half the screen (say the left), and two documents split the right side into two quadrants. These window management applications allow me to quickly reposition a given window with a key stroke as needed, depending on what I am doing.
To come back to nvUltra (or Composer)... I usually write with the preview off. When desired, I will toggle it on to get a quick look at my document, and then usually toggle it back off. If my window is smaller, I will usually toggle on Focus mode in nvUltra to hide the file list and give me more room. If I *really* need more room, I will use the window management app to make my window take up more space (e.g. full screen, or even top-half/bottom-half for extra width while retaining the ability to work on two documents in a single monitor.
The key in all of this is that I *don't* want the window size changing when I toggle on/off the preview, or other features. If the window grew wider unexpectedly, it would cover up the window to the right. Or even worse, try to expand right, but be forced to expand left because it is a right-sided window (assuming the preview is on the right).
I understand what you are saying about wanting to preserve your editing view and adding a preview to that. I just think the best approach to make that happen is different than your suggestion:
1. nvUltra is designed to work with Marked, so you can continue to use Marked as a separate window that you can hide or view easily. (See comment below)
2. You can use the approach I describe above to hide the file list and show the preview when you need it.
3. If that's not enough space, you can use the window manager of your choice to control the window size. Alternatively, you can switch to full screen before you show the preview, giving you plenty of real estate for both panes and not requiring any additional software.
4. You can use a fixed line width and the auto zoom functionality so that the proportion of your editor stays the same when you toggle the preview, though the font size will get bigger/smaller. (NOTE: There is a slight bug in the auto zoom calculations right now that probably are a side effect of one of the other fixes, but that will be fixed in a future beta version.)
But at this time, we are not planning on having the window intentionally resize when you toggle the preview on/off. I suspect that there is probably an alternative approach (either one above, or something else) that would offer you the functionality you desire. We'll also consider other possible approaches in the future as well.
(It's important to note that nvUltra is not designed to replace either Marked or Composer. Marked offers features that will never be included in nvUltra, just like Composer offers features that will never be included in nvUltra. These products each serve different needs. nvUltra is designed to quickly allow you to edit and search "notes" (where the difference between notes and longer documents is admittedly subjective.) Composer is designed to edit longer documents, which is where features like the interactive TOC come in handy. Marked is designed to offer an advanced preview of your file with many additional features. Certainly some users won't need the features of all three of these applications, but some will.)
0 -
To preface, as you say this probably isn't a major point of necessary debate for those that own Marked and intend to use it together with this tool. I certainly fit in that category, so to a degree I'm not really making this argument for myself. It's just something I think could improve the software generally, and that I feel this argument is compatible and symmetrical with the advice you're giving, to use Marked.To wit, my point can be best described in that suggestion: if one is encouraged to use Marked, then we are emulating this additive model precisely. You *append* a workflow onto the side of your editor (with another program). You don't shrink the editor down so that you can fit the Marked window into the space it used to occupy (what the preview pane does), no matter how efficient your window managing tools may be.So if appending is the optimal approach to previewing while editing, why have the preview pane use a different model? That's basically all I'm getting at.But as you say, not everyone might want that approach (just like not everyone might own or want to use Marked), so I think maybe this idea if it ever went into implementation, is probably one for a checkbox somewhere.0
-
If I may add to this: I love using Marked; my writing workflow requires it. That said, I also use transclusion, and currently Marked only displays transcluded files when they're at the beginning of a line, nowhere else. So for now, I rely on Composer's preview to see the contents of transcluded files in place (I'm just about to experiment with nvUltra's transclusion).
I confess that I've found it jarring to turn on Composer's preview and see my half-screen window halved, which is too narrow for me. I do use BetterSnapTool—so it's easy to quickly adjust the window to full screen so the editor and preview panes each get half the screen. So:
- we have users who prefer that the edit pane retain its size and the preview pane be added to it, and
- we have users who prefer that the window stay the same size and the preview and editing panes share that unmodified window.
Would it be worth considering opening preview in it's own window? I guess that makes it more like Marked. Perhaps that "off in the future" possibility Dr Fletcher mentions.
I do note that in the use case above, Dr Penney says that when he does preview in Composer or nvUltra, he usually just toggles it on, takes a look, then toggles it off. For that use case only, it doesn't seem to matter if the window covers another window: on, off, then back to writing. I take the larger point, though, as there are times when I need to see the contents of other windows for reference material, inter alia. In those instances, a new preview window would work better than two panes sharing one window. The new window would give me more flexibility as I usually have three monitors.
0
Please sign in to leave a comment.
Comments
3 comments