If I select a folder with a lot of documents, or with large documents, or if I accidentally select the Draft/Manuscript folder while in Scrivenings edit mode… wow, just waiting and waiting and waiting. Doesn’t seem to be a way to click out while Scrivener is trying to display the contents of the folder in the Scrivenings editor.
Would be a lot better if this code was written into a progressive idle loop so hat the user could click out or select a smaller subset of documents or folders. That way the user would never find themselves without agency over the application. The code could be written to display the first few docs and then cashe the rest in the background process that wouldn’t interrupt the user’s editing process.
I do have the same issue sometimes. It is not so much the number of documents but their size — I have the problem when selecting (let’s say) 20 documents if some have a lot of high-res images in their comments and/or notes. I do have a quite powerful MacBook Pro with 16 GB RAM but I am sometimes without agency for 30 seconds or so when selecting a folder with those documents while having Scrivening mode enabled. It is not a huge issue, but of course it would be nice if it could be avoided.
In most cases clicking on something else in the binder, or changing the view mode to something else (like corkboard), will cancel the scrivenings load immediately.
If you’ve hit a case where that doesn’t happen then you’ve hit a case where the software is so overloaded that it is not accepting input immediately, and has queued it for when it has the time to. There is nothing code can do about that as that’s a much deeper level scheduling thing that is more within the domain of the OS’s responsibility.
I recommend right-clicking on the header bar icon for this item and selecting the option to lock its group view mode (to corkboard, outliner, or single-item view). That way you won’t accidentally end up locked out for a spell, at any rate.
In this case, “a lot”, what slows down Scrivener to a complete stop when the manuscript folder is selected in Scrivenings mode, is just 20 or so chapters in a manuscript less than 270 pages long.
There are no sub-chapters or sections. Standard book length and structure. No font or style settings. Just text. No images. No figures. No tables. No internal or external links. Hardly any metadata of any kind.
How does one escape this loading mode once it is initiated? Why isn’t Scrivener looking for user input during the loading process? Why can’t I for instance, click on another binder item or on a different editor (standard, outline, cork-board) during this loading process?
My computer is not old. My hardware was top of the line when Scrivener 3 was introduced.
This is not the case. I’ve no other applications running. No background processes that are causing unresponsiveness anywhere else but within Scrivener. The OS is plenty responsive. The Finder is plenty responsive. I can navigate my way out of Scrivener without issue.
It is Scrivener that is non-responsive and only in the situation I have here indicated (when the editor mode is set to Scrivenings and a folder is selected. This is because Scrivener has not been coded to chunk up this load and display routine such that user actions can interrupt it. This is a big no-no in the coding of any user facing application. Luckily, it is usually remedied with a simple looping repeat structure with checks for user input. I am not complaining about the time it takes to display the contents of a folder, but that it has been coded such that the user can not interrupt this load and display routine.
Might want to have your coders look up google’s “map-reduce” algorithms. This isn’t complicated, just chunk up your processes into a loop that asks for user events at shorter intervals.
To wit, my two year old, bargain basement cheapest Mac you can buy can load 1.1 million words across 503 documents in 2.6 seconds. Even if I couldn’t interrupt it, I’d never care. Loading this thread probably took longer.
Yep, and my machines are fast as well. I am not seeing any such unresponsiveness in other apps running on these same machines and processing on far larger sets of data. It’s an easy fix. Any programmer knows how to fix this problem.
So Scrivener was designed and coded to bog down the computers owned by the people it was sold to? Your argument is silly at best. This isn’t a hardware performance problem. Anyone who has ever developed applications knows not to code it such that a click on an actionable element will cause the user to loose agency over the application. Such an easy fix. I design and write prototypes of user facing applications. I write them in a scripting environment that is not compiled. This means my code runs hundreds even thousands of times slower than compiled code. Even so, none of my application prototypes ever leave the user waiting, helpless, where they can’t click out of a process once started. Never. Yes, there is a tiny performance overhead introduced when the code is written to protect the user from loosing input agency, but it really doesn’t matter when compared to stranding the user in no-click land. I am going to present your little argument to my clients and see what their responses are. I know that I would fire any developer or development team that said what you have said here. No question. And so would every other development manager. The problem is unacceptable. The fix is easy. First rule of application development… NEVER put your users in a position where they can’t instantly click out of a process or routine.
Again, you are not commenting on anything I actually said (as I said before). Writing longer paragraphs about things I haven’t said, in response, is not a debate.