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 793893 - Color picker not picking color outside of Gimp window in Windows
Color picker not picking color outside of Gimp window in Windows
Status: RESOLVED OBSOLETE
Product: GIMP
Classification: Other
Component: Tools
2.9.8
Other Windows
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2018-02-27 18:53 UTC by Michal Vašut
Modified: 2018-05-24 19:14 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michal Vašut 2018-02-27 18:53:57 UTC
All of the Gimp window is OK, even window frame and its decorations (minimize, maximize, close), but anything else outside window border is unreachable for color picker. 

Tested on GIMP 2.9.8 (commit 18794a6ba2), Win7 64bit.
Comment 1 Simon Müller 2018-02-27 20:28:39 UTC
I just tested this myself (Win 10, same commit and also current master (b8aeed47)) and I was able to pick the blue color from the bugzilla title bar, even across multiple screens. We are talking about the color picker from the color dialog, aren't we?

What exactly happens for you with areas thatare "unreachable"? What color gets picked? Black?
Comment 2 Michal Vašut 2018-02-27 20:49:31 UTC
Ouch, it works now it seems, although halfway (compared to Linux Mint). The color is actually picked but:
 * cursor changes from picker to arrow (which doesn't happen outside of window boundaries in Linux and that's maybe the thing that confused me last time)
 * the elements outside Gimp window doesn't 'freeze' and the Gimp window loses focus after clicking outside of it (which doesn't happen in Linux I think)

Anyway sorry for false report, but other user had similar problem ( https://mail.gnome.org/archives/gimp-gui-list/2018-February/msg00018.html )
Comment 3 Jehan 2018-02-27 21:14:36 UTC
Simon > I believe you are our expert for Win32 code around here. I will let you decide what should be done and if you think things can be improved regarding the remarks in comment 2: cursor change and not giving focus to other windows.

If you think there is nothing to be done about this issue (because Win32 API maybe simply does not allow to improve these), feel free to close the report. :-)
Comment 4 Michael Natterer 2018-02-27 22:37:09 UTC
I think this is the 10th duplicate of some older bug...
Comment 5 Simon Müller 2018-02-28 00:05:33 UTC
Alright, I looked into the focus problem and this is what I found out to this point: Gimp uses gdk_pointer_grab to get all mouse events outside the window and gdk_pointer_grab in turn uses SetCapture () to capture the mouse. The documentation to SetCapture () (https://msdn.microsoft.com/de-de/library/windows/desktop/ms646262(v=vs.85).aspx) says this:

"SetCapture captures mouse input either when the mouse is over the capturing window, or when the mouse button was pressed while the mouse was over the capturing window and the button is still down. [...] If the mouse cursor is over a window created by another thread, the system will direct mouse input to the specified [the capturing] window only if a mouse button is down. [...]  Also, even if the foreground window has captured the mouse, the user can still click another window, bringing it to the foreground."

So this is exactly the behavior we are seeing here: Everything looks good as long as we stay inside the Gimp main Window but after leaving the Gimp window, Windows takes over, resets the mouse pointer and only lets gimp handle events that happen during a mouse click event (so that's why we can still pick colors even though it looks like the mouse capture is not working at all).


I don't see much we can do unfortunately except creating a whole new implementation of the eyedropper that forces you to begin clicking inside of gimp and then drag the cursor out onto the target area (That's the way it is done in the screenshot plugin and that would satisfy the "or when the mouse button was pressed while the mouse was over the capturing window and the button is still down" condition from above).
Comment 6 Michal Vašut 2018-02-28 05:53:09 UTC
Thanks Simon for your effort, good job. Well this is not bug only shitty behavior of Windows. It's more cosmetic problem (that can cause confusion), but fullfils its duty and at the end picks the color. As a reporter of the bug, I am accepting  this as a resolution. Let's consider it "Nice to have" feature with ultra ultra low priority.
Comment 7 Michael Natterer 2018-02-28 07:38:07 UTC
The OSX implementation makes a transparent fullscreen window and simply
waits for a click on that window, maybe such an approach can be used
here too?
Comment 8 GNOME Infrastructure Team 2018-05-24 19:14:23 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/1318.