I’ve come across a minor issue that, as far as I can remember, was not present in V2. (But maybe it was)
I often use a second monitor with my laptop. On that second monitor I will typically place Safari in one Space, and float a Quick Ref panel from Scriv on a second space on that monitor. I have the main Scriv window open on the laptop.
When I am using Safari for research, and swipe between spaces to get to the Quick Ref panel to make a note, the focus does not land on the Quick Ref panel, even if the cursor was previously active in that window. It lands instead on the main window, which means that I have to move the cursor and click on the Quick Ref panel or invoke the window switching shortcut.
Just to clarify, when I swipe to the second space on the monitor, the OS puts the focus on Finder. When I click on the Quick Ref window, the focus then immediately shifts to the main Scriv window, which means I have to click on the Quick Ref window twice.
Can I change this behaviour? I suspect it’s a Mac OS issue, but thought I’d ask. Thanks.
Unfortunately I don’t think I have the necessary equipment to really test this. I just have the laptop screen, and testing with virtual desktops alone, the behaviour is to retain the focus in the last used window of an application, if it is in the foreground, in that space.
So it sounds like there is an extra element of complexity between having multiple devices attached and using spaces within those devices. Maybe try messing with the settings in Mission Control and see if a different combination works better?
Thanks for looking into it Ioa, will play with the settings to see what happens. What makes me think think it’s a Scrivener issue, however, is that other apps (e.g. Safari, Devonthink Pro Office) don’t behave in the same way. They retain the focus in the last used window when swiping between desktops/Spaces.
I’ve just done a little testing, and it also seems to only affect Quick Ref panels. If I have another Scriv project open on the secondary monitor and swipe between desktops, when I return to that other Project window it retains the focus. I thought that was a workaround, but of course you can’t have the same project open in two windows.
(I hope I’m using Project window terminology correctly here).
It could be a difference in the type of window, or extra code that is being used to manage them, since they aren’t typically used like wholly discrete document windows (like two TextEdit documents, or two Safari browser windows). They are used more like satellite windows, and there is an extra code layer that works in aid of that—for example stuff that tries to keep them located in the Full Screen space they came from—a thing a normal window like a Safari window could never share with another such window.
So it is a little difficult to find comparisons in other programs. You need something that can load a window into Full Screen on top of a primary document, that isn’t a utility panel like the colour palette or the info palette in Preview, but despite that, can be in many ways treated just like a normal document window—moved to its own independent virtual desktop, put into tab view mode, etc.
Ah, ok, I think I see what you’re saying. The only app that comes to mind to test that with is Devonthink Pro Office. Using that app in the exact same way as I’ve been trying to use Scrivener – with a document opened separately in DTPO’s own text editor, on a different desktop to to the main window) – allows me to work in the way I expect (switch desktops, switch back to the text editor: focus retained and ready to start typing immediately).
Incidentally, and I’m not sure if it matters, I am not using Full Screen with any of my apps. I never do as I don’t like it as a general feature
Happy to send on any more details if you’d like me to, and I’ll keep experimenting with Mission Control settings.
No I wouldn’t say it matters directly (I’ve never quite understood the point of that feature either)—only to say that indirectly since there is code to make these windows act differently, there might be cases where this code does unexpected things, or makes the window act unlike other similar windows.
And in saying that, it might be a good idea to see if this situation improves in 3.0.2, once that is available. I am aware of one tweak that has been made to the QR panel windowing code that resolved a desktop migration issues (where in some cases the QR panel would follow you around instead of staying put). It could be we’re looking at something that is already fixed, intentionally or not.
