Scrivener 3 reveal in binder and right click behavior over binder

How do I reveal in binder? I used to use that all the time in Scrivener 1. It’s greyed out and only available in the context menu over the binder.

When I right click to get the context menu in Scrivener 3 for windows, it selects the current element as if I had left clicked on whatever binder element I happen to hover over and changes to that in the editor. I already have left click to change what I’m editing. It’s infuriating. So, even if I got reveal in binder to work (it’s greyed out), it wouldn’t show what I was looking for, just what I happen to hover over.

Reveal in Binder is available in the menu under Navigation/Reveal in Binder, shortcut key Win+Shift+R.
And it will be greyed out in the right-click context menu if you are already showing the binder. Move to a collection and right-click on an item and you will see it no longer greyed out.

2 Likes

Thanks for the save. It seems like it should be in the right context menu for the editor, but that solves my problem for reveal in binder.

Is it just me, or should right click to bring up the binder context menu, not change what’s being edited like a left click? Any insights on that one?

That’s a “feature” of Windows. The OS treats a right-click in many controls as “left-click then show context menu.” It depends on what you’re looking at, but lists, such as in the Windows File Explorer (or just Explorer) work the same way.

1 Like

It’s not just you. :grinning:

The context menu for items in the binder is invoked with a right click. As the OP describes, this will immediately change the contents of the active editor – unless that editor is locked, which is how I get around a number of “side effects” of how things work in Scriv.

Regardless of how right-clicking works in Windows Explorer (which typically does change the selection), in Scrivener, there should either 1) be a way to invoke a binder item’s context menu other than by a simple right click, e.g., with an Alt-right-click modifier, or 2) be alternate/additional ways to access commands that are now located only on the binder’s context menu. The way it now works makes certain features cumbersome to use.

For example, with two editors open, if I want to look at a third document in a Copyholder or Quick Reference window, I need to right click the doc in the binder, which in addition to opening the context menu to reveal an “Open” item and a submenu to select the CH or QR, will also update the active unlocked editor, just like a left click would. As a result, after opening the third document in the CH or QR panel, it will now also be open in the editor, forcing you to then click back to where you were before. That’s a lot of shuffling around!

Worth nothing here is that there is no “Open” submenu on the main Documents menu, as there is on the binder’s context menu. If there were, it could let you place items in a Copyholder or Quick Reference windrow utilizing the same submenu system to reveal project folders/files as do the Documents/Move To and Document/Copy To menu items. The option to do that seems to belong (that is, seems to be missing) on the Documents menu, which would let you access those great new features without unwanted changes in editor content – unless, again, the editor is locked, which is the easiest way around this particular issue.

This is where the ability to customize menus (in addition to greater flexibility in customizing toolbars and key commands) would be useful.

I looked in kb shortcuts, but there doesn’t seem to be anything that would let you open an empty CH or QR instance that you could then fill with the desired file.

Just for some futile fun I tried to see if using a modifier key when clicking or right clicking in the binder would do anything interesting and useful. But, alas.

2 Likes

There really are any number of reasons why one might right click a binder document, other than to open it in one of the editors – were that the goal it would be intuitively done with a plain old left click.

So I wonder how expected it is for a right-click, which typically brings up a menu of options/actions/etc (as it indeed does on the binder), to also initiate a substantive change in the state of the workspace, which is what happens on a binder right-click.

The options that are found on the binder’s right click menu may or may not cause an intentional change in editor content, but the right-click itself, which merely opens the menu to expose those options, should be invisible to the editors, as is the opening of any other menu or, say, simply initiating a project search. This might be more apparent now with the copyholder and quick reference windows evolving Scrivener 3 beyond the two editor model, which creates additional circumstances for accessing a document other than to open it in a main editor. But maybe those are only new in Scriv for Win, and have long been around on the Mac…?

Speaking of right clicks, I would love it if the Open menu also had the option to open a document’s sync folder version in a specified external editor for the specified file type.

2 Likes

All that navigation stuff is under the Navigate menu in v3, I think. Not at my PC to check though.

Frankly, I’ve always assumed that docs getting opened due to a Binder right-click was a bug they hadn’t gotten around to fixing. Or one they couldn’t fix. Because functionally it doesn’t make much sense to me.

Best,
Jim

1 Like

@JimRac: Frankly, I’ve always assumed that docs getting opened due to a Binder right-click was a bug they hadn’t gotten around to fixing. Or one they couldn’t fix. Because functionally it doesn’t make much sense to me.

I’m not sure what the status on this one is, though I can see it has been filed as a bug since 2018. Stuff like this is very often down to the programming toolkit, rather than something they have direct control over though.

@Mad_Girl_Disease: Regardless of how right-clicking works in Windows Explorer (which typically does change the selection), in Scrivener, there should either 1) be a way to invoke a binder item’s context menu other than by a simple right click, e.g., with an Alt-right-click modifier, or 2) be alternate/additional ways to access commands that are now located only on the binder’s context menu.

On that latter point, there shouldn’t be too many of those—we are careful to duplicate command interface as much as possible into the main menus, it’s just good for accessibility above all; not everyone has a mouse with which to right-click. I very, very rarely use the contextual menu in the binder.

As for those commands where you must use the binder contextual menu, I think this is it:

  • Show as Binder Separator: a very rarely used command, so not worth discussing in this context.
  • Bulk Metadata: the “Label”, “Section Type” and “Status” submenus are one of the few ways to set these metadata types to more than one thing at once. These controls are also available in the Outliner/Corkboard views, but more importantly, if you’re going to be Shift and Ctrl-clicking to get to that point anyway, then we aren’t even talking about pure single-click contextual menu usage anyway. If all you want to do is change the metadata for one item, the Inspector is available for that.

Every single other command in the binder contextual menu is found elsewhere as well. We do not view contextual menus as being primary tools, in other words. We view them as being an elevation of commonly used commands found elsewhere, as a convenience and as a way of highlighting features we want known.

For example, with two editors open, if I want to look at a third document in a Copyholder or Quick Reference window, I need to right click the doc in the binder, which in addition to opening the context menu to reveal an “Open” item…

That’s a good example in fact. This capability is not locked into the contextual menu, and I would say the most efficient way of doing what you want to do is to simply drag and drop the third item into side you want to add a Copyholder to, with the Alt key held down while doing so. You will note the binder selection does not change when doing so, and no navigation other than what you directed, occurs.

Worth nothing here is that there is no “Open” submenu on the main Documents menu, as there is on the binder’s context menu.

The “open” commands are all found in the Navigate menu. For example, “Open Quick Reference” bypasses the need for using the binder, and if you bookmark stuff you open frequently, can be more convenient and efficient than the binder.

The logic behind the menu organisation is described in the user manual introduction to Appendix A, in Table A.1. But briefly, the Documents menu is where functions related to the manipulation of binder items (documents) are found. Generally those commands will change the documents (hence “Move To”), rather than doing passive things like opening them somewhere.

Just for some futile fun I tried to see if using a modifier key when clicking or right clicking in the binder would do anything interesting and useful. But, alas.

You may have missed the Alt key. Alt+clicking loads the item in the split other than the one that would have loaded had you clicked normally (and will open a split if necessary, to do so).

I will say in conclusion, as a more subjective opinion, I have never found the burden of unwanted navigation to be very high in Scrivener. In some programs it would be very disruptive and frustrating if I couldn’t do a thing without navigating to that thing. But in Scrivener, with its long-memory history feature, there is almost zero downside to accidental or necessary navigation. Just hit Ctrl+[ and get back to work. No biggie, it’s more efficient than locking and then unlocking purely to avoid having to use history once, that’s for sure!

I do use locks, but only if I’m going to be doing a lot of binder management for a bit, to the point where history will no longer be a practical tool.

I just noticed this and thought it would be of some interest.

While it does seem generally the case that right-clicking in a folder structure will change the selection same as a left click, this pdf reader (PDF-XChange Viewer) does not. Seems fairly unusual, but useful. I just stumbled on it in a real world use case.

The first few clicks are left, the second few, right.

I don’t think that’s OS so much as control behavior in whatever widget set the application is using – and even there, the behavior may be selectable within the widget options. For example, I can right-click all around in a web browser without changing what is selected. Some text editors, right-click will change the selection point.

1 Like