This really more of a question than technical support, but can you tell me if the new Scrivener version will come with an option/ability to lock the binder to prevent accidentally moving files around? I know this is something that has been discussed previously, and asked for as an option… so I’m curious to find out if it’s something that is implemented in this new release.
When you’re in a nice writing fugue state, pinging around your binder and looking at character and research and structure notes, it is WAY too easy to reorder the binder and not notice it. I don’t care what sort of mousepad/tablet precautions you have taken, it will happen.
From a dev standpoint, it’s a no-brainer. It doesn’t change the experience for those who don’t want it, but really enhances that for those who do. And those who don;t think they want it: they probably will use it, and forget how they lived without it.
I’m a fan of this idea, so don’t get me wrong, but people have been asking for this feature nearly as long as the software’s been in existence–yet it hasn’t been implemented, which leads me to suspect it’s really not a no-brainer.
Hmm… If I were coding that, to avoid just what you’re saying, I’d write:
Drag Attempt:
If unlocked
–permit
If locked
– do not permit
– show warning modal window [This item is locked. Unlock to move it ]
But - that may prove to be annoying when user tested. “I’m using the binder and every time I accidentally flick over a file, I get this annoying modal window I need to click!” Now, that may be preferable that what happened to me the other day when one of my sections was inexplicably at the top of the chapter, not the bottom, but hey…
It’s doable, but where is it on the developers priority list and does it count as scope creep and bloat?
[Just a quick note on “No Brainer”. It’s not hard to think of, but could have complicated knock-on effects when dealing with something as basic as file structure which could require significant testing to prevent serious issues… so the cost/benefit analysis may just keep it below the line for features to work on…]
It might not be something they have managed to figure out at a technical level on Windows, but on a Mac you can undo changes made to the binder, corkboard and outliner. I’d say in general that’s a better approach than a separate feature that exists to make undo unnecessary, in that undo should in theory resolve any accidental edits.
I had thought undo doesn’t work with changes in Binder structure, but it … does? Just inconsistently. I just did a test and the first move of a document doesn’t undo - most of the time. But a beep. Then subsequent changes Do Undo! Hmmm…
Hmm, yes it looks like if you drag something without it being selected then undo doesn’t recognise the action, and then that blocks undo from working further. It might be a bug, I’ll check and see if that is something we can fix.
Replying a little late (lol), but the problems occur more when someone accidentally rearranges their binder and doesn’t realize it. When my friend first mentioned this to me, I thought “How do you not know you’ve moved something in the binder?” And then it happened to me this week. I have no idea when I accidentally moved a file, but I realized it today when I was getting ready for Compile.
A modal message asking if you really want to move a file when you have it selected to be locked is easy enough to handle, as is adding a little checkmark to the bottom of the screen saying, “Do not show this warning again.” The average person who clicks those kinds of checkmarks are the kind who know what they’re doing and if something doesn’t move, will say to themselves, “Oh, yeah… I locked that functionality…” So, that part is easy enough to cover. The actual coding of the locking of the binder, on the other hand, I have no idea on the complexity.
This is definitely a feature that many would love to have, though… #justsayin
How much software support work have you done? Because your description of the “average person” is adorably naive.
What will actually happen is that one group of people will forget that they locked the Binder or how to unlock it, and will respond with angry emails because Scrivener won’t let them rearrange their manuscript. Another group will blithely click through the warnings, move the documents anyway, and then send angry emails because Scrivener allowed them to rearrange their manuscript.
But locking the binder seems like not much of a solution. Like thinking a gated community will not have crime in it.
Recently, I dragged two chapters to the trash without knowing. I think I thought I was dragging something else. Later I emptied the trash. Gone forever.
But the thing is, I was trying to do something else when I made that drag, meaning if I could have locked the binder, I would have unlocked it to do what I was really trying to do. The ability to lock the binder would not have saved me from my error.
Things that are this destructive happen, whether you can lock the binder or not. Why not have a lock on the editor to prevent you from wrecking your great prose, too? As John Wayne would say, ‘it’s gettin’ to be ri-god-damn-diculous’.
This is what backups are for. To give us a way to resolve our f-ups.
Forever? Not really. I had a backup. Nothing was lost.
Just spent a half hour figuring out how to get back my binder structure after an undetected mouse slip. Questions:
Why does a binder lock have to be something hard to do/undo, or something likely to be forgotten? Why not an icon on the top? A button that’s easy to see and click would be a convenient option for unlocking the binder. Those who don’t want to lock it don’t need to click.
2, Someone suggested a screenshot of the folder structure. The problem is I’d have to open all the folders and do multi-part screenshot. Could there be a way take a “snapshot” of the folder structure within Scrivener?
There is the option of going to a backup to see the structure, but you’d still have to mess with screenshots, etc. depending on how bad the screwup was.
Because the guy who is in charge of implementing such a feature says it wouldn’t be as easy as people assume it would be, and that there would be additional support implications.
The question has been asked and answered, and in the absence of a new use case, it’s not likely to get revisited.