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 746639 - If enabled the applications menu extension in GNOME3 classic session, ALT+F1 key combination doesn't presents top bar categories
If enabled the applications menu extension in GNOME3 classic session, ALT+F1 ...
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: extensions
3.15.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2015-03-23 12:37 UTC by Hammer Attila
Modified: 2015-03-25 22:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
apps-menu: Clean up signal code (3.64 KB, patch)
2015-03-23 23:33 UTC, Florian Müllner
committed Details | Review
apps-menu: Move panel-main-menu handling into AppsMenuButton (3.53 KB, patch)
2015-03-23 23:33 UTC, Florian Müllner
committed Details | Review
apps-menu: Take over shortcuts again on startup-complete (1.30 KB, patch)
2015-03-23 23:33 UTC, Florian Müllner
committed Details | Review

Description Hammer Attila 2015-03-23 12:37:08 UTC
Dear Developers,

I don't no this issue is existing with the GNOME 3.16 version or not, I experienced following interesting thing in GNOME 3.14 classic session:
With oldest GNOME 3.10 release if enabled the applications menu extension in GNOME Tweak Tool/extensions preference pane, when I pressed ALT+F1 keystroke, presents wonderful the top bar and have possibility to jump between top bar categories. Me very helpful this working method, because I using Orca Screen Reader with GNOME releases.
I tryed now with GNOME 3.14.3 release with Manjaro Linux GNOME community edition. I selected the GNOME classic session in GDM login manager, and in GNOME Tweak Tool preference pane enabled the applications menu extension.
My experiences is following:
Before I not logout and login back, first time wonderful presents the top bar when I press ALT+F1 keystroke, and have possibility me to jump between top bar categories with arrow keys, TAB and SHIFT+TAB keys.
When I logout and log in and tryed press again the ALT+F1 keystroke, presents the overview, so I always need searching the top bar with CTRL+ALT+TAB keystroke when I want anything doing in the top bar.

This is a wanted change with newest GNOME releases?
If this is a wanted change, please provide keystroke possibility to presents the top bar without need doing more keyboard navigation, for example screen reader users this new keystroke is a big help.
With overview related have more keystrokes:
org.gnome.desktop.wm.keybindings panel-main-menu (I think this GSettings value containing default with ALT+F1 and SUPER+S keystrokes)
org.gnome.shell.keybindings toggle-overview
org.gnome.mutter overlay-key

Attila
Comment 1 Hammer Attila 2015-03-23 12:50:02 UTC
I see an another interesting thing this issue related:
When applications menu extension is enabled, and after the ALT+F1 keystroke doesn't presents right the top bar,
when I this situation launch GNOME Tweak Tool preference application, and in extensions preference pane disable and enable the applications menu extension, again works right this extension. This situation when I press the ALT+F1 keystroke, after ALT+F1 keystroke wonderful presents the top bar.
If I press ALT+F2 keystroke, type the r letter and press ENTER key, the issue begin again, I need manual enable the applications menu extension.

If your system doesn't possible reproduce this issue in GNOME 3.16 version, and after the applications menu extension enable the ALT+F1 keystroke 
always presents top bar, I experienced issue is a Manjaro specific thing fortunately.
If this is the case, sorry the unneed report.

Attila
Comment 2 Florian Müllner 2015-03-23 23:33:21 UTC
Created attachment 300161 [details] [review]
apps-menu: Clean up signal code

Setting up signal handlers inside a class and rely on outside code
to disconnect them via global variables is utterly weird. Just
disconnect everything inside the class when the corresponding actor
is destroyed.
Comment 3 Florian Müllner 2015-03-23 23:33:28 UTC
Created attachment 300162 [details] [review]
apps-menu: Move panel-main-menu handling into AppsMenuButton

This is really where it belongs, and will make an upcoming fix slightly
less ugly ...
Comment 4 Florian Müllner 2015-03-23 23:33:34 UTC
Created attachment 300163 [details] [review]
apps-menu: Take over shortcuts again on startup-complete

For a while now, gnome-shell has initialized extensions before
setting up its own keybinding handling. As a result, our taking
over of the panel-main-menu shortcut will be overwritten when
the extension is enabled at startup - work around this by setting
up the keybinding again on LayoutManager::startup-complete.
Comment 5 Hammer Attila 2015-03-24 06:11:13 UTC
Hi Florian,

Compatible your attachments with GNOME 3.14 branch version of gnome-shell-extensions source, or I need waiting with Manjaro update to gnome 3.16 version before I would like testing this attachments?

Attila
Comment 6 Florian Müllner 2015-03-24 08:33:13 UTC
The patches are against master, but they should work with gnome-3-14 if you change "Shell.ActionMode" to "Shell.KeybindingMode" in the last patch.
Comment 7 Rui Matos 2015-03-24 12:22:38 UTC
Review of attachment 300161 [details] [review]:

++
Comment 8 Rui Matos 2015-03-24 12:24:51 UTC
Review of attachment 300162 [details] [review]:

sure
Comment 9 Rui Matos 2015-03-24 12:27:24 UTC
Review of attachment 300163 [details] [review]:

looks good
Comment 10 Florian Müllner 2015-03-24 13:21:42 UTC
Attachment 300161 [details] pushed as 487c089 - apps-menu: Clean up signal code
Attachment 300162 [details] pushed as 8f4cecc - apps-menu: Move panel-main-menu handling into AppsMenuButton
Attachment 300163 [details] pushed as 0a5e5ee - apps-menu: Take over shortcuts again on startup-complete
Comment 11 Hammer Attila 2015-03-24 14:52:22 UTC
Florian, if not a big request, possible fixing this issue under gnome-3-14 branch too?
Ubuntu Vivid and Debian Jessie using GNOME 3.14 release and not will upgrading this distros with GNOME 3.16 version.

Attila
Comment 12 Florian Müllner 2015-03-25 22:11:18 UTC
(In reply to Hammer Attila from comment #11)
> Florian, if not a big request, possible fixing this issue under gnome-3-14
> branch too?
> Ubuntu Vivid and Debian Jessie using GNOME 3.14 release and not will
> upgrading this distros with GNOME 3.16 version.

It is probably as easy as comment #6 suggests, but I don't want to blindly push stuff to a stable branch - if somebody from those distributions can provide a tested patch, I'm fine with pushing it to the branch. However note that there won't be any more upstream releases, so in the end it'll be up to distributions to carry a downstream patch anyway ...