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 753419 - GUI blocks Canvas workflow
GUI blocks Canvas workflow
Status: RESOLVED DUPLICATE of bug 675549
Product: GIMP
Classification: Other
Component: General
git master
Other All
: Normal enhancement
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2015-08-09 15:57 UTC by Przemysław Gołąb (n-pigeon)
Modified: 2015-08-20 23:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Przemysław Gołąb (n-pigeon) 2015-08-09 15:57:35 UTC
This one itches me for some time, but it probably is a complicated matter.

Currently in Gimp, GUI and Canvas are in a way fighting for witch one handles the hotkey, which makes me sometimes confused and throws me out of working loop.

For example. I really like to work in F11-Tab mode no UI only Canvas, but then I turn on UI with Tab key for some Layers work and then I want to go back to Canvas. I press Tab but nothing happens "Ah... I again forgot to click with middle button to activate Canvas again...".

Same with Tools in Dialog. I open Levels edit, click canvas, open HueSatVal click canvas, open Curves.

I'm not sure about solution for this.
One option would be to make hotkeys global, but this will prevent using GUI with keybord...
Other would be Blender solution, to make hotkeys know the context by mouse pointer position. When mouse is on GUI it is GUI hotkey when on canvas it is canvas hotkey.
You then have to lookout for position of the mouse pointer, but it's smaller drawback than canvas clicking from my experience.
Comment 1 Michael Natterer 2015-08-20 23:08:15 UTC
This is a known issue that probably has no proper solution. Widgets other
than the canvas *can* have the input focus and must behave like normal
widgets.

We added a workaround for this: pressing Escape always moves the focus
back to the canvas.

*** This bug has been marked as a duplicate of bug 675549 ***