Feature Request

Could there be a toolbar item for the View menuitem to split the screen?

Thanks.

Vickie

But then there would need to be three toolbar items, one for horizontal, one for vertical, and one for no split. Remember that you can use the keyboard shortcuts to split the screen. I did think about a better visual tool for this, but I didn’t want to use toolbar items and there is no obvious place in the interface to put any split buttons… Hmm, I’ll think about it.

How about as optional in the ‘Customize Toolbar’ section, like the wonderous and delightfully unexpected ‘Toggle Rulers’?

Vickie

One traditional place to put split functions is tiny buttons at the top of the scroll bar area. Click once to split, click again to un-split, Opt-click to split vertically.

TAO can have multiple splits at once, so there is a button to close a split (the X) and right below it, to make a new one. These sets of buttons multiply for each split. In Scrivener, the toggle button could remain universal and at the top.

BBEdit has a drag handle in the same place, but you have to know what you are looking for to even see it.

Then, of coarse, there is the more modern Aqua based convention where a drag bar is presented at the top or bottom of the buffer area, but this would not work for Scrivener, as it only really makes sense for horizontal splits, and it would be really confusing (and ugly, I think) to have a vertical one too when the Inspector/Binder is visible.

Then the toolbar. You needn’t three buttons, I think. Just one. Holding down option would split vertically instead of horizontally. When a split exists in the document, the toolbar button changes into a “No Split” button. But I’m not sure I like the feel of having it up there. It is a very “editor window” specific function, something like text zoom. It would make more sense to have this button located in the header or footer, or above the scrollbar.

Hi. Vickie beat me to this one. I too would very much like a button for split view. I’ll be using this A LOT, as I’m sure others will, and it’s cumbersome to have to go the menu, etc. (I know I can do it via the keyboard, but I use buttons more often myself). It doesn’t really matter to me where it is as long as it’s handy.

AmberV’s solution seems quite workable to me—one button that toggles both ways depending on whether you have the option (or other) key held down.

But this was something that jumped out at me right away. The only thing so far but I am about to go through the whole tutorial now. I had time only to skim up to now! Fun time…

Alexandria

I can understand that Scrivener wants to stay clean and lovely. I personally favour the toolbar customisation to avoid the potential messy ‘three icons’ or ‘extra confusing stuff on the screen’ problem. (Isn’t it only two if you toggle splits?)

I always split vertically. If there were three (two) options in the customise Toolbar section, I would only put one of them on my toolbar. Maybe others have their individual preferences for splitting the screen.

Vickie

Having the buttons in the scrollbar isn’t really practical for Scrivener. Unlike applications that take this approach, Scrivener has numerous scroll views in each document view - one for the corkboard, one for the text view, one for the outliner view, one for the PDF view (which I have no access to as it is build into the PDF view itself), one for the web view (likewise), one for the image view… and so on and so forth. Thus I would need to put those buttons into about ten different scroll views and then deal with updating the lot of them - like I say, not practical.

I could have a toolbar item with a dropdown menu, but (like Amber V), I don’t think it should be a toolbar item.

I do have a solution, though, which I will run by you: the controls could go in the header view. Yes, you can hide the header view, in which case you wouldn’t have access to the controls, but that goes for the other controls in the header view anyway. This is how it would work: in the main document view you would have a little drop down menu on the right of the header view displaying three icons, one for each kind of split. In the second document view (the one displayed at the top or right), there would be a “close” button, which you could press to collapse the split instantly. I think this would be the best solution.

Let me know what you think.

Would work great for me. Sounds better than the other solutions in fact, at least to me.

Alexandria

Very nice. Very Slick.

Thanks,

Vickie

I think either the header or foot is a natural place to put these buttons. And between those two, I actually think the footer would be more appropriate as the header is all about navigation and document selection (true, renaming too, but that is gravy). While the footer is all about the document and how it is displayed – splits are a natural topical addition to it.

Opinions:
About the drop-down, personally I don’t like drop-downs too much for things like this. It increases action latency and requires secondary mouse pointing and activation. First the widget must be “found”, clicked, manipulated, and clicked again. Perhaps if it functioned like a normal button, activating the last selected split type, on a single click? Do you have something against the Opt-click method? And why have a second button for closing a split when closing is only relevant when a split is open, and when a split is open the split button itself is no longer relevant. Why not just have a single button that changes state smartly, depending on the application state. Unless you intend to have multiple splits in the future, like TAO.

I guess the biggest argument against it is that it is not immediately visible, what all this button can do. But given that 1/3 to 2/3s of its operations are irrelevant depending on the toggled state of the document, I think it is less of an issue. The main one is using Option to activate the secondary split type. On the positive side of that: It is a fairly common Mac-like thing to do. You do lose the full flexibility of the keyboard where you can switch split types on the fly, but I think that is a fair price for reducing interface clutter. You could have Opt-clicking on the close state button change split types, but would that be too much? Too many different button modes to keep track of?

One other opinion: If they do go into the header/footer, I don’t think the buttons should multiply into every instance of a header or footer. They should either stay stationary, or migrate to the centre-most instance, where the split actually is. Either way makes sense to me, for different reasons, but multiple buttons would look cluttered.

Nothing’s every simple, is it? :slight_smile:

Maybe I didn’t explain the “close” thing properly: the “close” button would only appear in the header of the document view that is created by the split (the one on the right or at the top). The “split type” button would only appear in the main document view that is visible whether there is a split or not.

Actually, the footer view is impractical for this for the same reason that a scroll bar is: the footer view changes depending on the type of document you are viewing.

I don’t really have anything against option-clicking except that it isn’t always intuitive and also I would have to subclass to be able to do it - it’s actually not standard behaviour of the default buttons… Although a menu may take a little more time, it’s minimal and I think it makes the most sense in this particular circumstance.

That makes a lot more sense, having the ‘X’ appear in the split header and leaving the split functions stationary at the top. I still think the foot is more relevant to splitting (and that makes me want to say the head is more relevant to spitting), but honestly that is a pretty minor thing. I doubt many people outside of UI experts and anal retentive perfectionists will ever catch it. :wink: