After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 687922 - Show applications does not work anymore
Show applications does not work anymore
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
3.7.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2012-11-08 12:16 UTC by Stéphane Démurget
Modified: 2012-11-17 02:03 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Stéphane Démurget 2012-11-08 12:16:44 UTC
While testing, I found that when I use Super+<A> to show applications, they are shown and the overview is hidden as soon as they are visible.

the release event is called just after so the the applications just appears and the overview is hidden.

This is a regression from Bug 683024 - "Entering and exiting overview have inconsistent key behaviour" where the release event is called just after showing the applications. No problem for the message tray and the app menu.

I'll try to find out a way to fix that.
Comment 1 Florian Müllner 2012-11-08 14:10:46 UTC
Another regression:
 (1) Go to overview
 (2) Open run dialog (alt-f2)
 (3) Hit escape to dismiss the dialog

As (3) happens on key-press, key-release will throw you out of the overview. Maybe we should consider just reverting the patch - as part of the keybindings-in-overview work, I have a (still rough) patch that moves all special handling of the overview key into mutter.
Comment 2 Stéphane Démurget 2012-11-08 15:23:54 UTC
(In reply to comment #1)
> Another regression:
>  (1) Go to overview
>  (2) Open run dialog (alt-f2)
>  (3) Hit escape to dismiss the dialog
> 
> As (3) happens on key-press, key-release will throw you out of the overview.
> Maybe we should consider just reverting the patch - as part of the
> keybindings-in-overview work, I have a (still rough) patch that moves all
> special handling of the overview key into mutter.

I do not understand, the run dialog is not a regression, as the code checks for the overlay key being released? It is not closing for any key released...

But the patch you mention should be better because not having access to keybindings in the overview is strange. I just attached a patch for bug 652082 in the same category, and not being able to use Super+<n> in the overview is bad, even if it is not happening frequently.

So yeah, it would be better to fix this once for all, you should revert it.
Comment 3 Allan Day 2012-11-09 11:08:57 UTC
It would be good to make system shortcuts like super+a (and in the future, super+m, super+ctrl+up, super+ctrl+down, etc [1]) work in the overview. One option there would be to not have the super key exit the overview if another key is pressed in combination. I'm not 100% happy about that though - you could go to use super+m, decide against it, and end up being forced out of the overview.

[1] https://live.gnome.org/GnomeOS/Design/Whiteboards/KeyboardShortcuts
Comment 4 Jakub Steiner 2012-11-13 10:46:23 UTC
Exiting overview on Super.keyup only when no other key is pressed does sound good to allow for the Super+? shotcuts to work everywhere. But that's me saying without the knowledge of what complexities that unleashes.
Comment 5 Florian Müllner 2012-11-17 02:03:21 UTC
(In reply to comment #2)
> I do not understand, the run dialog is not a regression, as the code checks for
> the overlay key being released?

Yeah, my bad - it is a regression, but from bug 687127 rather than bug 683024. I've attached a possible fix in bug 688196.

Since landing bug 688202, mutter's normal handling of the overlay key (activate on key-release, but only if no other key has been pressed in the meantime) is used in the overview as well.