Sb2: UI: minor: dock disabled during Exposé

The Dock never becomes visible and/or usable during an Exposé action while Scrivener is in full screen mode. It obviously should be gone in full screen mode, but it should come back or be able to be invoked during Exposé, without leaving Scrivener.

Besides giving non-Quicksilver people their expected ability to use the Dock as an app/document launcher without having to leave (and then return to) full screen mode, there’s another reason. I always take advantage of the Desktop’s clickthrough-like “inconsistency” with Exposé: when you’re in an application and hit the “Show Desktop” key, you can drag an item on the desktop around – including to the dock – without leaving the original app’s focus. The inconsistency is that the Finder would immediately get focus during the initial click, but it doesn’t, because being able to drag desktop items without leaving the focus of your active app is actually quite cool. I’ve become very used to this “functionality”; I’m in App X, and then decide to drag document Y to the Dock for whatever reason – usually to Trash it or Bluetooth it. I just hit “Show Desktop”, drag the item to the right part of the Dock – boom. But when I do it in Scrivener, I can’t get to the Dock unless I make an extra click on the Desktop.

Unfortunately there is nothing I can do about this. Check other full screen apps and see what happens (I am guessing the same). Scrivener hides the dock for full screen… And unfortunately Expose is a completely private API at the moment, which means there are no notifications that Scrivener can listen for to know that Expose has been invoked - Apple have made nothing like this available. I will look into it, but like I say, I don’t think there is much I can do. Thanks.

I know that iPhoto’s full screen editing mode kills the Dock, as does VoodooPad’s. I’d try MacJournal, but I deleted my copy once I tried Scrivener :slight_smile: – I only used it for full-screen mode. The only reason I mentioned it is because DevonThink somehow manages to preserve Dock visibility and functionality in full screen mode. Not that I think that much of its full screen mode… Sorry, this should really have been in “Wish List”, because I knew it wasn’t really a bug as such. :slight_smile:

Just downloaded MacJournal again, and yes, it somehow secretly preserves the Dock during full-screen mode. Of course, Scrivener’s full-screen mode is in most ways superior to those of other apps, so if your way of doing it precludes this, so be it.

I will look into this - if those guys can do it then I must be missing something.

Right, I’ve looked into this. Different programs take a different approach to full screen - generally, there are two different ways of doing it:

  1. You can hide the menu and dock and then create a normal borderless window that fills the screen.

  2. You can create a borderless window that fills the screen and assign it a window level of screensaver+1 - this will force the full screen window to cover the dock and the menu bar, which are still there underneath.

Scrivener, WriteRoom and Jer’s take the first approach; Ulysses and MacJournal take the second (as far as I can see).

Each approach has advantages and disadvantages. You have found the main disadvantage with 1) - it doesn’t play so well with Expose and the dock will remain hidden when hitting F9 or F10.

However, I believe that the advantages of 1) outweight the disadvantages - I find the behaviour of 2) much more “buggy”. For a start, using 1) you can have the menu bar pop down when you place the cursor at the top of the screen - you can’t do that with the second method. But the main problem with 2) is that because the window is set over the top of all others, panels will get hidden - they cannot pop up over the top of the full screen window unless they are assigned a higher window level. For instance, in MacJournal, whilst in full screen, hit Cmd-2 to show the calendar - it won’t show up. If you exit full screen, however, you will see that it was called up, but it just couldn’t be shown over the top of the full screen window. Or, in Ulysses, hit Cmd-F to do a find in full screen - the Find panel will not appear. If you exit full screen, you will see that the find panel was, again, called up, but it couldn’t show itself above the full screen because of the window level setting - in other words, in Ulysses, you can’t actually do a Find in full screen mode (in MacJournal, I see they have tried to get around this by implementing a different, “full screen”, find, which is much more basic than a normal find). Now consider how many panels Scrivener can display in full screen - you can see the find panel, you have the HUD panels, the snapshots panel and so on and so forth - all of these would get obfuscated by the full screen window if I took the approach of MacJournal and Ulysses.

So, this is a “swings and roundabouts” one, but the benefits of the current implementation outweigh its problems. Given that full screen modes are becoming more and more standard on the Mac, it would be nice if Leopard made their implementation easier and standardises behaviour, allowing some way of defining Expose behaviour etc… We’ll just have to see.

Anyway, I hope this explains why the current behaviour will remain, warts and all, and why there is not much I can do at this time.

Thanks and all the best,

A fine explanation – I thought as much.