Thanks for the new version and especially for the changes in the fullscreen-workflow stuff! It’s really easier this way!
One question – because I don’t know if it’s a bug or only the easiest way you found to solve this… –: when I’m on fullscreen and I switch programs with cmd-tab, Scrivener goes last on the list and I have to use cmd-shift-tab to go back to square one, is it supposed to act like this?
Hmm, that does appear to be the case. I wonder if this has to do with the new method it is using to duck out of the way. It might just be calling the system Hide command, which does put the application at the top of the “bottom” stack of stuff that is hidden or seldom used.
maybe connected with this: when working in full screen, switching spaces with “ctlr-arrowkey”, and going back to scriv, scriv is hidden and has to be unhidden manually. As I use spaces all the time on my macbook (have browser, mail running in other space), this turn out to be a little uncomfortable. But I will get used to it, I suppose.
For me, I have to do the cmd-tab dance twice to get back to Scrivener full screen. Each time Scrivener is nearly at the end of the tab-bar – omnifocus and terminal are actually right at the end.
In practice this means that I have to press cmd-shift-tab a minimum of six times to get back to scrivener. (More if I only use cmd-tab). It seems unlikely that this is the intended behaviour.
[More testing] This only seems to happen when Scrivener is on a different Space to the program I’m switch from. When they are on the same Space, Scriv is still two from the end of the cmt-tab bar, but at least it goes straight back to full screen.
In the grand scheme of things, all of this is fairly minor, of course.
The solution presented here is potentially needlessly complicated, but I’m fairly digging it. Use Spark (or some other tool that simplifies creating shortcuts for sending various commands to the program) to make a shortcut key combo to reactive Scrivener if it gets hidden. If I weren’t so tired and punchy now I’d probably be ashamed to admit I went and downloaded Spark just to try this out, but I’m enjoying it so much (consequences of my own repeated forgetfulness, I forget to close full screen when I switch spaces) that I’m wandering around looking for other things to apply shortcut keys too. That could just be because I’m procrastinating on my last 900 words for Nanowrimo…
Well, Scrivener 2.0 knocked you out of full screen altogether, but there were complaints about that. This is indeed caused by Scrivener being hidden when you exit full screen. I’ll look into it.
(Sorry. Please forgive my poor english.)
I upgraded scrivener 2.0.1. This version resolve lot of bug.
But fullscreen mode, It’s problem.
toggled to fullscreen mode
press command+tab, switch to other program.
scrivener screen is disappeared.
a few seconds later, scrivener’s fullscreen windows was appeared in background accidentally. Or, Scrivener’s fullscreen windows is going to foreground.
It’s curious. In scrivener 1.X, fullscreen mode was works flawlessly in background. (I can see black fullscreen window in background when I using other progrmas)
Hmm. I’m not sure this is precisely what djhan is saying, but I have noticed that occasionally when I switch Spaces with fullscreen open, I can switch back and Scrivener hasn’t hidden. I’ve installed Spark and have a keyboard shortcut to let me bring it back from a hide quickly, so I don’t know if that’s messing with Scrivener at all (I’m not using the shortcut in these instances, obviously–I just come back and Scrivener’s still up with full screen). But I’ll see if I can figure out if it’s reproducible at all, since maybe it is a bug that Scrivener isn’t always getting hidden.
I’m having a similar problem to those posted here.
I’m writing in scrivener, but using Zotero for sources. When I’m writing in full screen in scrivener and use cmd-tab OR the four-finger down swipe on my touch pad to switch over to the Firefox window with Zotero, Scrivener windows are automatically hidden and have to be manually unhidden.
Hi Roelder - That’s the expected behavior, that the Scrivener window will hide if switching applications when it’s in full screen. The oddity I was describing is that sometimes it doesn’t hide, which seems glitchy. But I haven’t figured out what causes it.
Hmm, in Scrivener 1.x, I am able to annotate my PDF files in Acrobat on my primary monitor while having Scrivener open in full screen mode on my second monitor. This is my default writing arrangement. Are you suggesting I’ll no longer be able to do this in Scrivener 2.x? Oh no!
If indeed this “feature” has been removed in Scrivener 2.x, perhaps this hiding behavior could be turned into a preference setting? Otherwise I’ll need to stick with 1.x!
Yes, due to some other technical issues that resulted from the way this worked in 1.x, it was changed for 2.0 and then changed again for a 2.x update. Keith’s looking into it, as he said, so he may find a different solution (though I think the above mention was referring specifically to the issue of Scrivener getting bumped to last place in the tab list). Sorry to disappoint!
OK, thanks. Well, given that Keith will be getting his hands dirty in this part of the code, I’ll just reiterate my plea to have a checkbox preference for “Remain in full screen mode when other applications have focus” (or something more poetic than that). This setting would apply to folks working with only one monitor as well, as they could CMD-TAB to a 3rd party application (e.g. to retrieve some important quote or data) and return to Scrivener in the same full screen state as they left it.
Thanks for whatever consideration you can offer this request.
Ah, I have a better idea. How about making the “Float Window” command accessible during full screen mode? This could either be a checkbox option in the hidden full screen toolbar options, or alternatively, if “Float Window” was enabled during normal view, it could remain enabled if/when a user switches to full screen.
(I realize this is a feature request, not a bug - but I’m including it here for continuity of the thread, and it seems relevant to any fix provided for the CMD-TAB issue)