But I haven’t heard anything recently. It hasn’t been implemented yet, has it? It’d be much appreciated–it’s WAY too easy at the moment to reorder something and not realize it. I just found out I sent something to the printer (5 copies, each 300 pages) with some sections out of order.
In terms of interface I already see three little icons below the “Binder”. How about a simple “Lock” icon that toggles between locked and unlocked?
I would really like this too. Scrivener isn’t very touch screen friendly and sometimes I’ll try to scroll down the binder and end up moving stuff or putting it inside an item.
I would like to strongly support this. I use a magic trackpad and scroll up and down the binder trying to find something. All of sudden something gets picked up and plopped down somewhere else. The only way I know to fix this is by opening a backup (glad that Scrivener does a good job with backups) and looking at the document order there.
In the Editor you can click on the document name on top and lock the document in place. Couldn’t there be something similar for the binder? It could be easy to turn off when you actually do want to move documents (which is much rarer than scrolling) and remain locked when you create new binder documents (something quite different from scrolling which I assume could be easily distinguished).
The ability to Undo binder document moves might be even more important. I’ve often had something land where I didn’t want it, and it is difficult to figure out how things were.
This is an old thread, but as someone that only just barely avoided publishing a book with a scene out of order… this feature is still desired! I have no idea how the scene got moved, only that it was correct when it went to the proofreader and sometime between proofreading and compile it was accidentally moved.
In the meantime, I’ve got a workaround: Add the whole manuscript as a collection once everything is in the right order, then work with it from the collection. If anything is re-ordered there, it won’t affect the binder.
+1 for this - there comes a point in the process when things are where they belong & it would great to know they’ll stay there no matter my errant clicks and drags
HUGE +1 for this. Other alternative suggestions – ranging from binder undo’s to better mouse pad management – do not address the core problem.
When you’re in a nice writing fugue state, pinging around your binder and looking at characer and research and structure notes, it is WAY too easy to reorder the binder and not notice it.
The argument that managing the locking/unlocking of the binder would become arduous – it doesn’t hold water. I want it lockable. Other users do, too. I will gladly accept any momentary frustration caused by trying to edit a locked binder …
Those who won’t accept that, they won’t lock it in the first place.
But you know what? I bet they will eventually lock their binders, too, after they find they’ve accidentally reordered their binder 3 weeks ago and only now are figuring it out.
When I was working as a programmer, I worked under one Chief Technology Officer who made a wise observation: Every thing is simple to the guy who doesn’t have to do it.
The easy solution is to use the Outline view as your index to the project. Changes to the Outline view are not reflected in the main Binder unless you explicitly transfer them, so it’s safe to putter around to your heart’s content.
On the Mac version, you can also use the Bookmarks feature as a Binder-independent path to frequently used files like research notes. (I’m not sure the status of this feature in the Windows beta. It’s coming if it isn’t there yet.)
If you’re finding that binder items are being moved accidentally, I would strongly recommend buying a new track pad or mouse, or checking their sensitivity settings. Dragging in the binder uses Apple’s standard dragging code, so is no more sensitive than any other area across macOS that allows dragging (and I can think of nowhere that dragging can be “locked” to avoid accidental drags).
@SteveCarterFrogStory: those were wise words indeed. In this case, to disable drags in the binder, the side-effect would be that you could no longer drag Scrivener links into the editor, or documents into the header bar, or all of the other things that drag can be used for; or it might disable all drags into the binder from elsewhere too.
Would it be worth the time to create a pinned forum thread that contains “Here are the things that have been asked for that we are definitely NOT doing” topics?
You guys have a great app so please stop the buck passing.
Consider a response like this:
“We use the standard drag/drop code, but I can see from the number of people expressing a problem with this that we need to find some solution, whether that’s a lock, and undo, or something else. Please understand that we have a lot on our plate but we take all feature requests seriously. We appreciate the feedback. Thank you.”
Whatever in his response made you think that KB doesn’t take the request seriously? You have literally zero clue of what kind of engagement tech support has had with these kind of complaints and what issues they found in common, but I’m willing to bet KB knows quite well, which tempered his response. There are seldom technological solutions to behavioral problems.
People around here take simple time estimates as gospel truth and throw hissy cows. Something like what you said above would be seen as a promise to implement the feature yesterday.
I don’t think you understand what “buck passing” means. Or perhaps - regarding the link you include with “buck passing” - you expect me to remove Apple’s spell-checking system and replace it with one that I write from scratch myself, a project that could take years? Because that is the only way to fix something that Apple does not provide access to. Or perhaps you have technical knowledge I do not, and could tell me how I am supposed to access Apple’s drawing methods in NSSpellChecker, something built in down at the system level, so that I can fix an Apple drawing glitch that has been around for years? Not everything is technically feasible. To explain as much to users is not “buck-passing”.
And as for the current reply, that fits your accusation even less. I am explicitly saying that I do not intend to implement a binder lock, because I don’t think it is necessary or desirable - and because I cannot implement every single user suggestion.
Perhaps you should consider this: I’d rather be honest with users and tell them when something isn’t likely to happen (and why) rather than indulge in the vague corporate waffle such as you suggest.
But I take your suggestion seriously and appreciate the feedback. Thank you.
This happened to me on Saturday. I was on my MacBook, I unintentionally dragged a document from one position to the next, no idea where it ended up.
The only way to fix it was to open a backed up version of the project. Take a screenshot of the order of the (58) documents, and go through them manually until I found the one that had been misplaced.
Indeed, if all you want to do is move the file back to where it should go, you can drag and drop it straight out of the Quick Search result list. You don’t need to know where anything is stored, if you know the name or a bit of text from it.
Dragging in the binder uses Apple’s standard dragging code, so is no more sensitive than any other area across macOS that allows dragging (and I can think of nowhere that dragging can be “locked” to avoid accidental drags).