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?

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 )

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. :-)

I think this is the 10th duplicate of some older bug...

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).

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.

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?

-- 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.