A feature I would love: A Scrivener file format that puts UI state information into its own file(s), separately from the project content and structure information.
This would allow me to configure my version control system to ignore changes in UI state.
Check out the Window/Layouts/Manage Layouts… feature. It’s not quite what you are asking for, but can give you the same end effect, by storing the UI state to a file, and then being able to easily apply that state to any project window in the future.
That would help me switch UI states easily. That’s not what I’m asking for.
I want to tell my version control system (usually git) not to bug me about file changes if all I’ve done is open a file, navigate around in it, and select stuff.
Currently, simply opening and closing a Scrivener file changes at least these files in the .scriv package:
I want to put document content and binder structure under version control. But I do not want to put UI state under version control. I don’t want UI state changes to show up when I ask git for a status.
I think I can safely instruct git to ignore the first three files.
But if I understand correctly, the .scrivx file includes UI state, binder structure, and perhaps other stuff.
Because the .scrivx file includes binder structure (which I want to track), I can’t tell git to ignore it. And because I can’t ignore it, git ends up tracking UI state changes, which I do not want to track.
In essence, I want to be able to instruct git to track only the content and structure, but not UI state.
Does that clarify what I’m asking for?
Okay, there isn’t a clean way of doing that then, as you’ve surmised. Ignoring the first three in the list would help, but you’re still going to tick some files over whenever you open a project and do more than close it immediately, there is no way around that, and ignoring the .scrivx file wouldn’t be a good idea as that has all of your Binder information. Even the ui.plist file, while it wouldn’t hurt to ignore it, contains stuff you might want to have retained, like Outliner column settings—pretty much anything you can set up about a project using the main menus is stored in that file.
That’s the present tense. For the next major version of Scrivener, we are already taking steps to keep settings separate from UI details where possible. Some of the lines are pretty blurry. Is having the Format Bar enabled a setting or a UI state? Well it’s both, which is why it is currently in a file that handles both of those things at once, but the main idea is to get things to a point where it is closer to what you want—where you can click around and select text without potentially incrementing any data files that you would definitely want to preserve no matter what.