Right-click of document or containers

[dbc183c7]

Why does a mouse right-click of an item open it in the editor?
Not only do I lose sight of what was being shown in the editor but there are several tasks on that menu for which I'd not need to see the item's text. (I'd likely want to view my reference material in (an)other editor window, but given Scrivener's lag-time in dealing with my multi-MB containers, it introduces a distraction whatever I wanted to do; even the RC menu takes seconds to load.)

(I was looking to the RC/"Menu > Documents" Open ... to get me around Windows' 'not responding' and 'stopped working' messages for Scrivening's difficulties with MB+ documents -- but that issue is for another forum post.)

[Windows 7, 8 GB; Scrivener 1.9.0.0 (trial)]

[AmberV]

There is unfortunately no way around the fact that a right-click is a click, that’s just how the system interprets things. What you can do however, when you wish to use the Binder without changing the editor, is lock the editor (§9.3.1, Locking the Editor, pg. 81 of the user manual).

[dbc183c7]

Thank you Amber ... that handles the situation.

I realized after I sent the post that it is normal for even a right click to take the focus away from where it had been, but I was surprised by Scrivener's spending cycles on displaying a ~ 4.7 MB scrivening that I did not need to see before it allowed input for the context menu. (It takes ~ 33 seconds! )

On another point, the context menu's path's endpoint (and that of the application's window's menu as well) ends with "On other editor corkboard";
It would be handy to have a similar option for the outline view.

I don't suppose I can set a default view for a container ... ?

(I do appreciate that there is a shortcut and that it toggles the locking on/off.)

[AmberV]

Yeah that goes back to a deeper problem we still need to resolve. We need to fork loading into an interruptible process so that if you accidentally load several megabytes of text at once, you can just click somewhere else and stop, without any lag in doing so. Right now the loading process occupies the main thread, which to be fair is the safer and much simpler way of doing things (hence the way it is).

On the question regarding why you cannot load a flat list of items into the outliner, what were thinking of doing with such a view? The reason for that feature’s existence is that Corkboards are, by nature, one level of outline from one container at a time. This command gives those who prefer the corkboard a sort of way of viewing “whole trees” at once. With the Outliner, you already have that capability built into the premise of the feature with collapsible containers, and viewing multiple levels of outline with that tool needn’t necessarily restrain your ability to change it (whereas flattened corkboards cannot be modified as many card movement attempts would have no logical outcome on the underlying outline).

Well, if you do want a flat, non-interactive list in the Outliner you can do so (since you like shortcuts):

• Alt-] to expand all.
• Ctrl-A to select all.
• Ctrl-Alt-Return to load all selected items in the other editor (or Ctrl-Shift-Return to replace the current editor with the selection).

Normally, I would use that technique to narrow down an outliner list and focus on just a few items—but if you just want to flatten the outline it works fine with Ctrl-A instead of selective picking.

I don’t suppose I can set a default view for a container … ?

It is done naturally through use. If you change the view mode to Outliner it should go on using that until you change it to something else. If you mean setting a default view for one specific container alone, that isn’t currently possible—but it is a planned feature.

[dbc183c7]

Amber, thank you.
Lots of handy info here ... and as a 28-year programmer before retiring, I 'd on reading the details.
(No response necessary! And thanks for the peek at the future.)