scrot not working via hotkey if drop-down menu of source window is activated
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| scrot (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
Bug Description
I've just discovered this bug when I was (desperately) trying to document an issue in gedit which showed here a certain drop-down menu as blank, no menu items.
scrot ALWAYS goes on strike when you have hotkey set to PrtSc (for example) and you want to document a bug in a window. So in that source window, you would show the dropped-down menu, and THEN hit the hotkey for scrot.
Result: Nothing.
You can almost bet your life on it that once you retract the drop-down menu (i. e. so that it doesn't show), scrot via hotkey will work fine again.
Proved easily by polling my $HOME for new files. Whenever I hardcopied a window w/its menu dropped down = no new files.
Would be great if this could be fixed. Unless...it's not a scrot issue but has to be reported upstream (DE? WM?) No idea where, really.
| description: | updated |
| summary: |
- scrot not working via hotkey if drop-down menu of window is activated + scrot not working via hotkey if drop-down menu of source window is + activated |
| IFo Hancroft (ifohancroft) wrote | #1 |
This is not a scrot issue. Any hotkey pressed after an application's drop-down menu is opened, goes to the application. The hotkey never reaches your shortcut manager so scrot is never invoked. I can't remember how I verified that. As far as I remember, the window manager is responsible whether the application or the shortcut manager gets the hotkeys.
Please correct me if I'm wrong, or if you manage to find either a screenshot tool, an X window manager, or a shortcut daemon that manages to work differently.
A good workaround, in-order to be able to screenshot the drop-down menu, is to invoke scrot with a 5 second delay, after which, click the drop-down menu to open it.