The subject line says it: I often set up a whole (UHD) screenful of QR windows in very particular configurations of size and position (and other settings). This serves me so well – until I have to exit Scrivener. The next session requires me to manually set up the whole thing again. If only I could save a few Layouts, with the QR windows, for these specific workflows . . . .
Thanks in advance for considering this. (Or for pointing out that I missed an existing feature.)
Hi again.
I believe that indeed that can’t currently be done.
If my memory serves right, it has been discussed in a thread somewhere. Feel free to hop in.
Else, do you know that using copyholders you can have a configuration (savable/recallable, size and all) of up to 4 editors? (2 editors, 2 copyholders)
Perhaps that would do?
Indeed, preserving a layout with 4 copyholders would go a long way toward what I want! Thanks for the tip. I haven’t used copyholders, other than to make a few and remove them.
I just discovered that the last paragraph of a Format (of text) doesn’t honor or save the alignment and indent of the rest of the layout. And that it was reported in 2011. Uh-oh. I’ll pursue that in a separate thread.
You can even have a fifth one, sort of, using bookmarks.
Hmmm. Can copyholders float? That’s relatively essential…
That is, when I double-click the copyholder icon and it DOES float, is it still a copyholder object?
Not to my knowledge. (Answering first of two posts.)
And I am still away from my computer. Can’t check.
The Manage Layouts window seems broken. When I create a NEW layout, it shows up on line 3 of the layout list. Except for NEW, the entire list is blank, but the first two blank entries seem to have layouts when I click USE. And there’s no way to change the name of the NEW layout.
Belay that. I think there was an old layout called NEW, which I took for a command to create one. I’m now operating the manager properly, and it seems to work.
When a copyholder is popped out to float, it becomes a Quick Reference, and isn’t preserved in a Layout.
I’ll have to experiment with various copyholder setups. Fortunately, my main computer has a UHD screen, 50", so there’s room for a huge Scrivener instance.
I think the big challenge with this request is that the layouts feature as currently designed is not specific to individual projects. As you’re asking for project-specific layouts that remember QR panels containing specific documents in specific locations for your specific screen resolution, that sounds to me like a significant overhaul of the implementation.
So it seems unlikely that we’ll see this anytime soon. But –
Like you, I’m a big user of QR panels, and I’d be extremely happy if Scrivener could simply remember which QR panels were in use when I last exited the program, and reopen them again when I launch the program. If it could also remember their screen positions, that would be icing on the cake, and I think would give you most of what you want. 
Best,
Jim
Yes, that’s exactly what I want (for the time being). And I could live with it only applying to the last session … Setting up a bunch of QR windows is quite a task, at least the way I would use them if they were preserved.
I’ll dream of Scrivener someday being able to preserve project-specific layouts including, well, everything!
Just as a note to the overall feature request, this is unlikely to ever be added for one simple reason: with one very small exception, Layouts have nothing to do with projects.
They are a generalised tool for reproducing layouts across whatever projects you use. Quick Reference windows are intrinsically bound to one very specific binder item from one specific project. They are a window that exists for that singular purpose of displaying the content of that one item.
The other issue is that I primarily see this being suggested as a way of solving a bug: QR panel are not saving their position and settings persistently across session. Spending inordinate amounts of time solving a bug with a completely different system that has nothing to do with that bug is not the best way to fix bugs. 
We should just fix the bug, not potentially create a dozen more.
As for why they don’t save Copyholders, the main issue there is again a somewhat project-specific problem. If the copyholder is not built with specific UUID from your project window then it comes up what, blank? So now you’ve got to use a menu command, or drag an item from somewhere into the header bar to make this blank rectangle eating up part of your screen useful—and guess what, that’s exactly what you do to make a Copyholder in the first place.
So we’ve saved you nothing by stashing it in the layout and restoring it upon use, zero benefit to your efficiency, for the cost of providing something that always loads up awkward and empty (useless).
It’s an idea we’ve tossed around a bit in the past. The main issue with going in that direction is that it would pretty much mean having to commit to it fully. The notion of having a set of broadly useful layouts you use across all of your projects, past, present and future, would have to be abandoned for a system that forces you to recreate those setups in every project, every project template you create.
It wouldn’t be terrible, but when considering the benefits vs what is lost, it’s debatable as to which is clearly better. And if you’ve got a problem like that where there are a lot of pretty strong pros and cons, then overall radically changing a system to work another way is usually not the best path to take. For one thing, you’ve got a lot of silent people out there that are using layouts the way they are, and if we take that away from them and make it a project-only tool, they will no longer be silent about it.
Thanks, AmberV.
I’m a little confused (in a new way 
). I see that QR panels are intrinsically tied to a specific project, so their states can’t be saved as part of an “application layout.” But you mentioned a bug “QR panels … not persistent across sessions.” Does that mean QR panels are supposed to persist?
Does that mean QR panels are supposed to persist?
Precisely, in several different ways.
How wonderful! Will persistence include their open/closed state? IOW, when I open a project, will the QR panels that were previously open be restored? Or will I have to re-open them manually?
Yes, part of that includes adding a setting to restore open QR panels on project load. We don’t have that currently because the result of that setting would be a mess of stacked identically sized windows in the middle of the screen.
This is terrific news. It completely fulfills my wishlist item, so I’m now looking forward to the next feature update even more enthusiastically.
I really appreciate the deep support you provide us, no matter how naïve we may be about how Scrivener works.
From a developer perspective, I could see that half-implemented functionality as being undesirable to release. But from a user perspective, I’d much rather have Scrivener remember the open QR panels, even if it meant they were restored to the middle of the screen.
In case you’re having to hunt through the binder at the start of each session, looking for a bunch of documents to open as QR panels–
Create a new collection, and add to it documents that you regularly open as QR.
Then, when you next reopen Scrivener, instead of hunting through the binder, select all the documents within that collection and then press the Quick Reference button on the toolbar. You’ll still need to go through the process of positioning them where you want them, but opening them all up will be a breeze.
Best,
Jim
Thanks, Jim. That’s good advice. I’ll do it.
Cheers,
Allen