?? Really ??
What is a secure lock? One that the user can’t remove once in place ?
A secure lock would keep other people from changing your project. But the rtf files would always be accessible, so a secure lock is impossible.
Ahhh… OK.
But that’s a completely different thing.
Here we mean protecting the binder against undesired changes. Protecting the user from him or herself, sort of.
Not locking the project as some sort of overall protection.
One alternative that could be interesting: the ability to take recallable snapshots of the binder…
2 Likes
(After the thread was merged with this old one, here → )
I’ve read Keith’s argument(s) and reason not to want to implement this, but perhaps, one thing that could make everyone happy would be to have an option that once toggled, you’d need a modifier key along the mouse click and drag for binder elements to be movable. ??
That wouldn’t negatively affect any functions, whiles at the same time offer a certain level of binder protection to those (such as me) who would like to have it. (?)
It seems to me that this is a basic functionality from the point of a common user. From my beginnings when using Scrivener, I realized that it was very easy to move documents by accident. I think that every rookie incurs this error. Some even think that their document has disappeared or deleted instead of within another document or folder.
I do not know the technical difficulties, of course, but this should be easy compared to the powerful existing features. In my opinion, it would be enough that together with the “Binder” (title under the main menu) there was an icon with the symbol of a lock to avoid movements in the order of the documents while closed. Perhaps, while it is closed, the document listed could show a degraded background of dim yellow.
The user would only have to click to open or close the lock and this would affect all documents (this eliminates the difficulty of establishing variables for each one) and only from the point of view of the Binder, not in the editor or in compiler. Another essential function that seems to have been lost in the new versions is blocking the view of a document in the editor [Solved! 
Thank you, Vincent] . It is also very useful for not opening another by accident.
Anyway … developers are free to do the program as they wish, but I think that sufficient people have expressed themselves in this same direction over the years. It seems that there is a phobia to “block things.”
Regards.
This is now here:
Right click the document’s icon in the editor’s header.
1 Like
When one person asks for something its a one off but when many people, some of who has monster sized binders ask, it’s time to look at alternatives. Perhaps everyone can find something to agree on.
Okay, that’s fine, time to explore other options
This probably is not impossible, however, I did notice that once you close out of the file that all undos are gone, and of a quick typo fix, “oops I dragged scene E to scene B, creating a sub scene by mistake but didn’t notice it so I closed out” issue could be catastrophic to the entire file. It happened to me once keep reading.
So instead I suggest a history of binder changes log. a note of “(time & date) E was moved onto C” would be perfect, especially if it logs like up to 20 changes. Label it binder change log and you do not have to mess with the drag and drop system. You could even be fancy and have a restore function but merely listing the changes could really help all users who suffer from this issue.
omg I know, I had just got finished with my first book and sent it off to the vanity press (I did not know that was what it was) and the editor looked it over and gave it an okay. I decided to read the compiled document and discovered that a character sheet, with tables and everything was somehow placed in the middle of the book. And Tate Publishing said the file was fine! thank goodness I found it and yanked it. Long story short tate went under I got stranded after paying 3k into it (grr)
oh yeah, I totally forgot about that feature, I was doing some advanced editing needing 2 panes and had a hard time there for a bit.
(edited to reply to people)
1 Like
By the way, there is a bit of cross-feed with another thread I just posted in, wherein I described a way of backing up the order of the binder, that might of be interest to those in this thread.
It does require one to be a little pro-active, but it’s a small task all around; a few clicks for some peace of mind.
First, follow the instructions in the upper portion of this post, to create a linked and indented list of items in your binder as it stands.
Proceeding from that point, take a Snapshot of the link list (Ctrl+5 / ⌘5). You’re done for now. You have a redundant hard copy of the list in a snapshot that cannot be accidentally messed up.
Now as a test, move an item or two around in the binder and repeat the procedure of creating a link list of the whole draft, pasting the result into the same document, updating the main text.
Use the Navigate ▸ Inspect ▸ Snapshots menu command (or however you prefer to get to that place in the inspector), select the snapshot representing the initial state of your binder, and click Compare. I would suggest changing the comparison mode to “By Paragraph” in the option button to the right of the compare button.
A line marked as an addition is where the missing document was moved to, and the line marked as a subtraction is where a document was moved from.
The only real downside is that it is something to remember to do after you have made any real changes of substance to the binder order. It’s a less than critical downside though, as the side effect of not remembering to do this often enough just means there will probably be more change lines to jump through and disregard as intentional edits, either to title changes or shuffling the order on purpose. You’ll still find the error, in other words, it just won’t be the only two lines in the comparison view.
But for those that make a habit of it, this technique would also be of general interest in seeing how your binder order develops naturally over time, as well, with a sequence of snapshots taken at notable points of revision. I.e. it doesn’t just have to be a recovery tool, it can be useful for seeing how the work is proceeding.
1 Like
Isn’t this what backups and the save as functionality are for?
Just open an old version of your project.
Where this offers a different capability to backups is that there is no way to compare the binder order between two open projects (without essentially doing what I just described anyway). So if the main issue is as described above, some kind of mechanical/human error that causes random unknown items to end up being dumped into random unknown locations, then two side-by-side lists of how the binder looked before vs how it looks now, wouldn’t be terribly useful. You’d have to read through it all by eye, one line at a time, looking for differences. What you’re looking for may be in a horrible area for finding it to, like the unstructured mass that is eight years of Trash folder contents.
Why do that when you can just click a button that shows exactly what went where? And if this is something that happens with some regularity, why not just keep that reference handy instead of having to acquire the list from another copy of the project?
I suppose if one has done very little or nothing other than open their project and move files around chaotically, then sure, rolling back to yesterday will suffice. Anything older than that, and just fixing the binder is more efficient.
So that’s it, it just provides another tool, one that is in my opinion more completely overlapping the problem with a solution than the more general purpose backup restoration or reference approach (which is of course, always there and always one’s ultimate safeguard).
What are you people up to that this is a problem?!
If I poured a bucket of catnip in the keyboard, tied a real mouse to the mouse and then put the whole lot in a small box with eleven cats and a Jack Russell, it still wouldn’t cause this kind of disruption.
I get that you might purposefully decide to play around with your structure to see how it looks, but in that case just use backups to see what you had before and move it back.
Note as well that a binder lock function wouldn’t solve any of these problems.
1 Like
As I quickly, very quickly summarized, in my case it is because of a functionality issue when running Scrivener on my windows tablet.
Scrolling the binder often leads to unwanted files displacement.
It also somehow seems worse lately.
Perhaps something to do with a recent Windows update.
(I doubt the recent Scrivener QT change could have in any way affected the scrollbars touch-sensitivity wideness.)
(And as far as I can tell, my fingertips are still the size they’ve been for a good while.)
Actually, it could have done. It may very well have changed slightly how the various library stuff that is used for the binder responds to inputs (eg sensitivity for what is consider a click-hold-drag rather than a mouse move) in order to make manipulation easier (remembering that it’s only really the iOS interface that is optimised for touch as a primary input method). Although to be fair, a change in how this works at an OS level is also plausible.
In the meantime, have you tried writing so slowly that you rarely need to move your binder? I’ve been working on the same chapter for two and a half years and it’s completely removed any problems in this area.
4 Likes
You can laugh at the requests of other users (it is evident that you have fun in these forums), but that does not change the reality described by many people in this thread. You are overlooking that there is no keyboard shortcut to undo a document reorganization and that this can direct data loss by an accident, regardless of backups.
Here it has nothing to do with making backups, but we talk about unwanted behavior.
Given that other requested solutions are not likely to happen(^1) because (a) technical limitations and (b) design principles, I genuinely believe that no solution is better than retaining an actual copy of what your binder used to look like so you can actually look at it and use it as a guide for a manual fix… and the good news is the functionality already exists and requires no prior prep from the user (unless they’ve disabled backups for some reason - in which case you’re pushing your luck looking for sympathy for data loss issues).
I strongly recommend laughing as much as you can and having as much fun as you can. Both are excellent, and don’t hinder one’s ability to give good advice.
(1) - the good news is, if you want some lottery-odds type hope… KB has been known to release features shortly after I’ve declared it impossible.
2 Likes
Feature Request: Folder and Document Structure Locking
Description:
I would like the ability to select multiple folders and documents within a Scrivener project and lock their structure in place. This would prevent accidental movement or rearrangement during normal use, such as when moving other files, creating new files, or reorganizing the project.
Specific Issues Addressed:
- Accidental Folder Movement: Folders sometimes get moved into other folders unintentionally, disrupting the intended hierarchy.
- Level Shifting: The level (indentation) of folders can accidentally shift to the left or right, again affecting the organization.
Desired Functionality:
- Selection-Based Locking: Allow users to select multiple folders and documents and then apply a “lock” or “fix structure” option.
- Structure Preservation: Once locked, the relative positions and levels of the selected items would remain fixed, even when moving other items around.
- Unlocking: Provide a way to unlock the structure when needed, allowing for intentional reorganization.
Benefits:
- Improved Organization: Maintain the intended structure of complex projects, especially during active development and revision.
- Reduced Errors: Minimize the risk of accidental changes that could disrupt the flow of the manuscript or lead to confusion.
- Enhanced Productivity: Focus on writing and editing without worrying about constantly checking and correcting the project structure.
Additional Considerations:
- Visual Indication: Consider providing a visual cue (e.g., a lock icon) to indicate that items are locked.
- Context Menu Integration: Include locking and unlocking options in the context menu for easy access.
- Compatibility: Ensure that locking functionality works seamlessly with other Scrivener features, such as Compile and Search.
Thank you for considering this feature request. I believe it would greatly improve the usability and reliability of Scrivener for projects with complex folder and document structures.
1 Like
I think you’ll find there is discussion of this already in the forum together with explanations as to why it hasn’t been implemented.
Mark
1 Like
I have read them. That is why it is a feature request and not a bug fix; it might require doing somethings differerntly.
I’ve been bitten by the problem being discussed a couple of times. In those circumstances, the result was a mild panic sometime later, and a simple fix. Nevertheless, it would be comforting to be able to lock the Draft structure to circumvent it altogether.
It seems you haven’t read them all, as your new request has now been merged with one of the existing threads requesting this feature.
It’s obvious you spent some time on your thoughtful, detailed post. Which is unfortunate, as upthread KB (Scrivener’s primary designer) has already stated his “sorry, no” on this feature.
Best,
Jim
2 Likes