Too many here to read them all…Searching didn’t find any of these. I’m relatively new to Scrivener, so if some of this is already in there, please point me to it. Thanks.
The ability to undo binder changes made by dragging entries up and down.
Some visual feedback when clicking the top level folder to open the comlete project in the editor. Right now it just sits with no indication that it’s doing anything. Annoying with a long project with many documents.
The search dialog should respond to Esc and have a Cancel button. Standard GUI. I press Esc every time only to realize I need to click the x button to make the dialog go away. Annoying.
When displaying Search Results, need something like F3 to go to the next found argument in the document. I have to scroll down and hope I don’t miss one.
This one is a little difficult to pull off. Undo stacks, as they are technically referred to, are tricky to deal with and making even the slightest changes in how they work can cause bad things to happen to them. It’s a recognised issue, and the way we’ve approached this issue is by making the design as relatively non-destructive as possible. You move an item up, you can move it back down. You trash it, you can move it back out the trash. You split it, you can merge it. It’s not the best, but there are very few things you can do that make a truly unfixable mess of the binder. This approach is not unusual in software design. Many programs opt to treat certain activities as non-destructive and omit them from the complexity of the undo system, very intentionally to keep it as clean and safe as possible.
Yes this is already a planned improvement; and along with that the ability to seamlessly cancel what looks to be a long process. If you click Draft and you didn’t mean to, you shouldn’t have to wait thirty seconds, you should be able to click elsewhere and cancel it immediately.
Esc works on my computer. Are you saying if you press Ctrl-F you can’t press Esc to close the box?
That’s a planned improvement as well. When using Project Search, the criteria you type into the field will be automatically added to the Ctrl-F box behind the scenes so you can just hit F3 to jump to the next match.
If it’s any help–and if you are coding C++, it might be–I published an undo/redo template class library in Dr. Dobb’s Journal several years ago. Generic undo/redo. I’ve used it on several projects, and it really takes the complexity out of the code. I think you can find it along with the article on the ddj.com site.
The problem I’ve had with this behavior is that I use the Binder’s vertical scroll bar, and miss. I’m dragging in the binder rather than in its scroll bar. I’ve moved something before I realize that’s what happened, and it’s not always evident where it came from. (It’s a big manuscript with many folders and documents.)
On the Find dialog, Esc works if I do Ctrl+F and don’t search for anything. If I do a search, Esc doesn’t work. Here’s why. After the search, focus is on the document, whether anything was found or not. To get Esc to work, I have to click back into the dialog box to return focus to the dialog so that Esc works. Many applications leave the focus with the dialog until it gets changed irrespective of whether anything is found. Take a look at how Word does it for example. I’m guessing that that’s how most users are used to the Find/Replace dialogs. In any event, you also need a Cancel button if you are striving for a standard user interface. The little X works, but that’s not its purpose.
Thanks for the quick reply and for considering these comments.
They are using Qt/C++, and I’m so I think it is Qt that is complicating the undo situation. Thanks for the tip though, I’ll pass it along. Accidental drags are a problem with the current setup; no debate with that. This is something they want to do, maybe the above will give some ideas.
“Cancel” strikes me as an odd UI implement. It is traditionally provided when the other available choices are destructive. You accidentally close a window and are asked if you wish to save, discard, or cancel and go back to where you were. There is no such “Oops” scenario in a Find box. You either need it visible or you do not. Looking around I see people do put “Cancel” buttons in Find box, all right, so it is conventional—but it doesn’t really make much sense. “Hide” or “Close” would be more accurate. At any rate I do see what you mean with the focus issue, I have in fact been bothered by that before and keep forgetting to bring it up, so now I shall write up a ticket for it.
When you have several parts that can have undo/redo, it is usual to implement them independently each with their own stacks. The problem is when you “do” something, change to a different part then try to “undo.” Anyway you undo it can be confusing.
I agree about Cancel and Close. In that kind of dialog, they are the same thing.
Right, that is what we are currently doing. Each text file has its own stack, as well as text fields in the inspector; a neglected mistake in the synopsis needn’t be blocked by a few hundred its in the main editor. It’s a matter of running a new loop shared between the binder, outliner and corkboard views, which is where I think it gets a bit sticky, especially once splits come into play and you can have multiple corkboards and a binder that all communicate between each other, but are showing different things. It would probably require a hand-built stack to pull it off, since all three can be looking at different places. “add object X” cannot be enough to undo the removal of X if the left corkboard is looking at one container and the right corkboard another. Anyway, I’m not familiar enough with the code to get much further into this conversation, all I do know is that I’ve been informed that it is difficult.
“Hide” or “Close” would be more accurate. At any rate I do see what you mean with the focus issue, I have in fact been bothered by that before and keep forgetting to bring it up, so now I shall write up a ticket for it.