GNOME Bugzilla – Bug 652346
Alt-Tab menu should not appear when instantly releasing keys again
Last modified: 2011-08-03 15:26:30 UTC
When one quickly switches to the last used application, the Alt-Tab menu appears even though the user doesn't need to look at it. This creates a visual disturbance which looks like flickering. The proposed fix is to wait for a very short time before showing the menu (say 250 ms), and if the user has already released the keys in this time, don't even show the menu. IIRC, Mac OS X and Windows also behave like this and it makes a difference in the "feeling" the UI gives. (Don't know if this belongs to mutter or gnome-shell.)
Created attachment 189770 [details] [review] altTab: don't show popup immediatly in case the user is fast enough We wait a short bit before doing the initial tween to fade in the popup so that fast Alt+Tab users aren't disturbed by the popup flashing in front of their work.
Created attachment 191364 [details] [review] altTab: try to avoid showing the switcher when "flipping" Use a longer fade-in time, but with an inout transition, so that the dialog starts fading in very slowly and then picks up speed after 200ms or so. That way if the user releases Alt+Tab right away, they'll never actually see the dialog.
Comment on attachment 189770 [details] [review] altTab: don't show popup immediatly in case the user is fast enough This looks like it should work... but I'm attaching a simpler alternative. Does the timing on that patch work for you?
Review of attachment 191364 [details] [review]: Yes, this seems to work too and it's simpler and safer than mine. The timing is about right I'd say.
Does the opacity stay at 0 long enough with this transition? A quick calculation shows that it's only for about 40 to 60 ms that it stays at 0.
The idea is that it's "close enough" to 0 for longer than that. See the graph at http://hosted.zeh.com.br/tweener/docs/en-us/misc/transitions.html. Plugging in the numbers, it doesn't reach 10% opacity until 154ms, and then it reaches 90% opacity at 247ms. So it's pretty close to "invisible for 150ms, then tween in over 100ms, then fully visible after that". (Note that the dialog is fully reactive even when it's at 0% opacity, so the fact that it's not really *fully* visible at 250ms doesn't matter.)
pushed... git bz flaked out somehow
I looked at the graph and even looked up the formula and put in the numbers. My point is that "pretty close to invisible" can still be noticeable and distracting. Oh well, I guess I'll have to wrestle with jhbuild again and try it out. In any case, thank you both.
But if users do want to see alt-tab bar to pick the next app, it feels slow. Perhaps speed it up again when users press tab the second time and the bar has not been shown yet?
agree that it feels slow now... but speeding up on second Tab press isn't the fix, because the user may want to see what the first Tab would go to. OS X appears to not have a fade in; the dialog appears instantly at full opacity if you haven't released Alt after a certain interval. (It does fade *out*, just not *in*.) Maybe we should do it like that.
Created attachment 192330 [details] [review] altTab: do a step transition instead of fading in Commit 7596fdb46091c7b224dc3d1b64b95252cec1b468 makes the popup feel slow. Instead of fading the popup in we wait a bit and show it instantly. Based on attachment 189770 [details] [review].
Comment on attachment 192330 [details] [review] altTab: do a step transition instead of fading in This feels good to me; long enough to not pop up when I release Alt quickly, but short enough that it doesn't feel delayed when I keep Alt down. Can the people who have commented previously try this out and see if it works for them? >+ this._initialDelayTimeoutId = Mainloop.timeout_add(POPUP_DELAY_TIMEOUT, >+ Lang.bind(this, function () { >+ this.actor.opacity = 255; It seems weird to immediately show it with opacity 0, then later on change the opacity to 255. We should just not show() it until the timeout.
Created attachment 192340 [details] [review] altTab: do a step transition instead of fading in Commit 7596fdb46091c7b224dc3d1b64b95252cec1b468 makes the popup feel slow. Instead of fading the popup in we wait a bit and show it instantly. -- show() the actor only after the timeout.
Comment on attachment 192340 [details] [review] altTab: do a step transition instead of fading in >- if (this.actor.visible) { >+ if (this.actor.visible && this._initialDelayTimeoutId == 0) { you don't need this change any more; the timeoutid should always be 0 if the actor is visible. good to commit with that fix
Attachment 192340 [details] pushed as 10a0f2b - altTab: do a step transition instead of fading in Committed without that hunk. Thanks Dan.