Hi,
I am using Scrivener 3 for Windows, and was just using the ‘Lock Inspector to Current Editor’, and have a few questions about that.
I have my screen split, with a different document in each split pane.
I could have sworn that in previous versions of Scrivener for Windows, there was the same little padlock at the bottom right of the screen that there is (apparently) in the Mac version of Scrivener, but I cannot find that - if I am right about this, is there any way to make the padlock icon visible?
I would like there to be a padlock icon because the only ways to lock the Inspector to the current editor (document) are for me to go Navigate - Editor - Lock Inspector to Current Editor, or to go into Help - Search Menus - [type] Inspector - [and choose] Lock Inspector to Current Editor.
I find this incredibly clumsy.
If there is no padlock icon, is there another, quicker way of enabling/ executing Lock Inspector to Current Editor?
You would think there would be a quicker way to activate / execute Lock Inspector to Current Editor, because a small white letter ‘i’ in an orange circle appears when this command is activated, and one can click on the ‘i’ to turn off Lock Inspector to Current Editor - surely, if this command can be turned off with a click, one should be able to activate it with a click, or am I being naive?
While I am on the subject of locking, if I lock the editor itself, and then click on either of the carets at the left of the top bar of each split pane (the carets invoke either the ‘Show previous document viewed.’ and ‘Show next document viewed.’) will go straight to either the previous or next document - i.e., clicking on the carets will transcend the locked status of the document - is there any way to truly lock the document so nothing (other than unlocking it) will move it from being displayed on screen?
That does the trick for accessing the Lock commands…
I just added a question about truly locking the editor so that the ‘Show previous document viewed.’ and ‘Show next document viewed.’ carets are prevented from working - is that possible?
By curiosity (and to make sure (a refresh) I ain’t talking through my hat), I tested the caret with the editor locked in place : the caret is ineffective.
(Only the left/right (history) ones do something still. – Perhaps an oversight, I don’t know.)
If the binder order document up/down ones remain functional at your end, then there is a setting (that I never knew of) somewhere…
I would classify the Navigate command as being more of an accessibility fallback then what we intended as the primary trigger for those that use this frequently.
You’ll find the methods listed in §13.1.1, Locking the Inspector, but in short: just right-click on the inspector tab bar area. The visible button was removed because this is not a very commonly used feature, and it was confusing those were making its usage more common by sheer accident and then wondering why the inspector didn’t work right.
I just added a question about truly locking the editor so that the ‘Show previous document viewed.’ and ‘Show next document viewed.’ carets are prevented from working - is that possible?
No, the rationale of the lock button is not to protect you from yourself, so to speak, but to stop all forms of passive navigation that would change the contents of the editor by merely clicking on things in other editors, or the binder. It’s not going to stop you from clicking a button, or using a hyperlink, or anything that could be interpreted as a deliberate attempt to navigate away from what you’re doing. It used to work that way, ages ago, and it was quite frustrating because most often when you click a button you really want the button to be clicked, and not have to wonder why nothing happened, and then remember why, and then turn off the lock, and then click the button.
(And yes, there are bugs in the complete implementation of that rationale, and you spotted one of them. It makes no sense to block you from being able to jump to the next document in the list, but not block you from jumping to the last thing you looked at.)
As a simple mortal user I have no explanation for this unexpected behavior…
But as I said, consider the fact of clicking on those as denoting your intent to bypass the lock. So just don’t click them if you have no intention of navigating away anyway.
Yes…but sometimes in my not-so-precise-hand/eye-coordination the proximity of some of those icons to the others means that I accidentally click on something I had not intended to click on: that is why the older functionality that Amber talked about would be preferrable for me.
View / Editor Layout / Header View ← no buttons to accidently click.
[Edit] And now that I think of it, don’t confuse Lock in place with Lock inspector to Editor.
Quite possibly in the current case (I believe you first asked about the latter), the bug is not that the history arrows work, but that the next/previous in binder ones don’t. [@AmberV ]
(It’s in the title too.)
I think you might be using the wrong function for what you need, simply.
. . . . . . . . . . . . .
[EDIT 2] I just tested Lock in place and the navigation carets (history – at first I thought all four did, but I only noticed the lock being toggled off too late) toggle off the lock. So I don’t know for sure what should be, but in the case of the inspector being locked to the editor, I don’t see any good reason why it should lock the navigation at all. [And it doesn’t.]
If you want the inspector to stick to whatever document is in the left editor (for e,g, – don’t show me the right editor’s metadata – don’t care), that doesn’t mean that the content of that said editor should be prevented from moving on to another document. You’ve locked the inspector to this editor, not the editor.
. . . . . . . . . . .
[EDIT 3] Sorry for such a messy post.
But clearly along the way the two different locks you (and perhaps Amber too) confused as to what was actually the topic and (in your case) intended functionality.
[Heck, I think even I, got confused at some point. When I said this :
Bug or not, If I were you I’d just use this for the time being :
I was aware of the difference between Lock Inspector to Editor and Lock in Place.
And I have the View - Editor Layout - Header View displayed.
What I meant about accidentally clicking buttons is that sometimes I move my mouse across there, intending to click on the document icon (next to the file name), and I accidentally click on the Show next document viewed caret.
@AntoniDol might know of a way to spread them apart using a theme. (Cross your fingers, you never know.)
My previous post was about the fact that seemingly we’ve been drifting from the behavior expected of one lock to the behavior expected of the other without ever really naming the second (lock editor in place).
And my overall point is that part of the way the word “lock” is defined in Scrivener does not (ironically, for a piece of software to do with writing) truly represent the meaning of the word.
Actually, my original question was, “If there is no padlock icon, is there another, quicker way of enabling/ executing Lock Inspector to Current Editor?”, meaning, specifically, having a clickable icon visible to lock (as well as unlock) the Inspector to the Editor.
Maybe it got missed, but is the right-click not efficient enough? Sure, you may have to move the mouse a few pixels before letting go of the button, but it’s pretty close to having a button.
Sorry for having only just got around to answering this now.
A clickable icon is, for me, a far more preferrable option - maybe it is just the way my brain works, especially when I am trying to concentrate on writing: I do not want to have to have to break focus for a couple of seconds to try to bring something else to mind (in this case, a right-click) - I just want an icon right in front of me.
Well, I don’t think it was stated in this newer thread, but in older ones: the button itself was removed years ago as it is a very low-use feature. I strongly doubt it will come back and it is best to get used to the “new” method.
The visible button was removed because this is not a very commonly used feature, and it was confusing those were making its usage more common by sheer accident and then wondering why the inspector didn’t work right.