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 308516 - printscreen or ALT-Printscreen keys don't work if whatever gtk menu is open.
printscreen or ALT-Printscreen keys don't work if whatever gtk menu is open.
Status: RESOLVED NOTABUG
Product: gtk+
Classification: Platform
Component: Widget: GtkMenu
unspecified
Other other
: Normal normal
: ---
Assigned To: Jonathan Blandford
gnome-utils Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-06-21 12:49 UTC by oll
Modified: 2008-03-09 11:16 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10



Description oll 2005-06-21 12:49:58 UTC
Distribution: Fedora Core release 3 (Heidelberg)
Package: gnome-utils
Severity: normal
Version: GNOME2.10.1 unspecified
Gnome-Distributor: GARNOME
Synopsis: printscreen  or ALT-Printscreen keys don't work if whatever gtk menu is open.
Bugzilla-Product: gnome-utils
Bugzilla-Component: screenshot
Bugzilla-Version: unspecified
Description:
Description of Problem:


Steps to reproduce the problem:
Just one example amongst a lot 

1.  Open Gedit
2. Click on View and let the menu open
3. press alt-printscreen

Actual Results:
Nothing happens


Expected Results:
Preview of gnome-screenshot should appear


How often does this happen?
Always

Additional Information:
Of course, running
 "gnome-screenshot --window --delay 5"

allows to take screenshot of open menus but it's easier to use key
shortcuts.




------- Bug moved to this database by unknown@bugzilla.gnome.org 2005-06-21 12:49 UTC -------

Comment 1 Sebastien Bacher 2005-10-19 13:27:03 UTC
Thanks for your bug. That's not a bug and not specific to this feature (try to
alt-tab with the menu open by example). GTK needs to grab the keyboard events
for the menu accelerators.
Comment 2 hamfbohne 2008-03-08 14:49:26 UTC
I don't get why this shouldn't be a bug.
In my opinion, this is a very ennoying bug.

Example:
When I listen to a playlist while navigating through menus in another application and the next song in the list that is played is to loud (e.g.), I want to be able to turn down the volume fast (with the help of the volume-down-key on my keyboard) and without having to close all the menus.

I suggest reopening the bug. 
+ http://bugzilla.gnome.org/show_bug.cgi?id=144907 is a valid bug and assigned.
Comment 3 Emmanuele Bassi (:ebassi) 2008-03-09 09:28:45 UTC
(In reply to comment #2)
> I don't get why this shouldn't be a bug.
> In my opinion, this is a very ennoying bug.

it's not a bug, it's a side effect of the required behaviour of the menus in gtk+; without it, you wouldn't be able to navigate in menus using your keyboard.

read the explanation in comment 2.
Comment 4 hamfbohne 2008-03-09 11:16:17 UTC
I've read comment 2 but (as said) I can't quite follow the arguments. 

* »(try to alt-tab with the menu open by example)«
  -> Well... Nothing happens. (What did you expect to happen?) I would expect that either the menu is closed and the focus switches to the next window or even better: The menu stays open is and the focus switches

* »GTK needs to grab the keyboard events for the menu accelerators.«
  -> Right. But none uses the print key or any other multimedia keys as menu accelerator!? + only single keys are used as menu accelerators (provided that I understand the term »menu accelerator« correctlys. Menu accelerators are the underlined letters of menu entrys?) so there's no reason for Ctrl+X Alt+X,... not to work.

My point is that no single shortcut works while a menu is open.

Example I: (concerning »navigation in menu using your keyboard«)
1) Open a menu by using Alt+F
[see: _Print  ...  Ctrl+P. Recognize the big Ctrl+P rather then the little line under the p as shortcut/accelerator.]
2) Press Ctrl+P to print.
[notice: nothing happens. Unexpected!]
3) Use the arrow keys to navigate to »Print« (this is what the not-that-advanced-users tend to do) OR Press p 
  -> the print dialog opens as expected.

Example II:
1) Open a menu (Alt+F)
2) Navigate to a sub menu and search the menu for a specific entry.
[imagine: the entry you look for is not in this menu. think: then it has to be in the »_Tools« menu]
3) Try to open the Tools menu by using Alt+T.
[notice: nothing happens]
4) Try to open the Tools menu by pressing T
[notice: the »Impor_t Wizard« pops up. Unintentional!]
[Either you know that you have to press the arrow-right key several[1] times to go to the Tools menu or you try the following:]
5) Try to focus »File« using the arrow (up/down) keys. Doesn't work. Use the mouse to do that. Press T. It finally works and you're in the Tools menu.

I hope you got what my arguments are... It's almost as frustrating to do something and see ... nothing ... happen as it is to see that something unexpected happens.

Imho this is even worth a new bug because (as explained in ~40 lines) it does not only affect the print/... key but all shortcuts.



[1] The bad thing about this is: You don't know how many times you have to hit arrow-right to get where you want until you do it, because the first menu item could be a sub-menu (try to go from »File« [Alt+F!] to »Help« in Evolution for example)