Colo Picker eyedropper not working properly inside the Blender preferences window #111295

New Issue

TheRedWaxPolice · 2023-08-19T14:37:14+02:00

TheRedWaxPolice commented

2023-08-19 14:37:14 +02:00

System Information
Operating system: Win 10

Blender Version
Broken: blender-4.0.0-alpha+main.1ce9c2b1f831-windows.amd64-release
Worked: builds from last week, maybe

Short description of error
When you try to pick a color using the eyedropper inside of the blender preferences window, it doesn't work properly. It just keep changing to an arbitrary grey color...

Exact steps for others to reproduce the error
Use the eyeddropper to pick any color inside the preferences window. The result will always be an arbitrary grey color... See the attached vid...

**System Information** Operating system: Win 10 **Blender Version** Broken: blender-4.0.0-alpha+main.1ce9c2b1f831-windows.amd64-release Worked: builds from last week, maybe **Short description of error** When you try to pick a color using the eyedropper inside of the blender preferences window, it doesn't work properly. It just keep changing to an arbitrary grey color... **Exact steps for others to reproduce the error** Use the eyeddropper to pick any color inside the preferences window. The result will always be an arbitrary grey color... See the attached vid... <video controls="" src="https://projects.blender.org/attachments/b48fa5f9-962a-44ad-850d-6822e37ae681"></video>

blender_f13ne7xTMO.mp4

811 KiB

TheRedWaxPolice added the

labels 2023-08-19 14:37:14 +02:00

YimingWu commented

2023-08-20 03:53:06 +02:00

Can confirm. The eye dropper is picking color from the main window instead of whatever is on the screen directly.

Also the eyedropper seems to be averaging samples from mouse dragging while button down (This might be the expected behaviour)

d20f26aeb6 seems to be correct.

likely caused by 5741a5d433

Can confirm. The eye dropper is picking color from the main window instead of whatever is on the screen directly. Also the eyedropper seems to be averaging samples from mouse dragging while button down (This _might_ be the expected behaviour) d20f26aeb67 seems to be correct. likely caused by 5741a5d433cd6555b608b94

YimingWu added

and removed

labels 2023-08-20 04:33:58 +02:00

YimingWu commented

2023-08-20 04:46:19 +02:00

Caused by 5741a5d433 @Harley

(that patch also doesn't seem to enable eye dropper outside blender window... on linux here 🤔 )

Caused by 5741a5d433 @Harley (that patch also doesn't seem to enable eye dropper outside blender window... on linux here 🤔 )

YimingWu referenced this issue

2023-08-20 04:48:06 +02:00

UI: Linux & Mac Support for Eyedropper Outside Blender #111303

Harley Acheson self-assigned this 2023-08-20 05:26:04 +02:00

Harley Acheson commented

2023-08-21 18:02:30 +02:00

Thanks for this report. This one is very interesting.

In order for this improved functionality to work we need to know which window we are picking from. That uses WM_window_find_under_cursor. AFAIK the last time I was mucking about in that function it was a bit of a mess, in how it had to basically guess which window was visible under the cursor. The "guessing" because we don't really have a sense of "z-order" with our windows.

But that function looks to be refactored beautifully and perfectly for this use. But it is made to work perfectly only if given per-platform help in the form of a specific ghost function. Without that it defaults to looking through each window in turn and checking if the cursor position is within window bounds. Because the main window is before its children in the windows list it will return the main window first when the two overlap. That default behavior - in GHOST_IWindow *GHOST_System::getWindowUnderCursor - should probably be checking the windows in reverse order. I'll probably ignore that though and add a specific replacement for Windows that use the real visible z-order.

It looks like I just need to make a Windows-specific getWindowUnderCursor function. Should be quick and easy and can get it reviewed through the platform module.

Thanks for this report. This one is very interesting. In order for this improved functionality to work we need to know which window we are picking from. That uses `WM_window_find_under_cursor`. AFAIK the last time I was mucking about in that function it was a bit of a mess, in how it had to basically guess which window was visible under the cursor. The "guessing" because we don't really have a sense of "z-order" with our windows. But that function looks to be refactored beautifully and perfectly for this use. But it is made to work perfectly only if given per-platform help in the form of a specific ghost function. Without that it defaults to looking through each window in turn and checking if the cursor position is within window bounds. Because the main window is before its children in the windows list it will return the main window first when the two overlap. That default behavior - in GHOST_IWindow *GHOST_System::getWindowUnderCursor - should probably be checking the windows in reverse order. I'll probably ignore that though and add a specific replacement for Windows that use the real visible z-order. It looks like I just need to make a Windows-specific getWindowUnderCursor function. Should be quick and easy and can get it reviewed through the platform module.

👀 1

Harley Acheson referenced a pull request that will close this issue

2023-08-21 20:24:51 +02:00

Fix #111295: Add Missing Win32 Platform-Specific Window functions #111359

YimingWu referenced this issue

2023-08-22 04:27:08 +02:00

Fix #111295: Add Missing Win32 Platform-Specific Window functions #111359

Harley Acheson referenced this issue

2023-08-22 05:04:25 +02:00

Fix #111295: Add Missing Win32 Platform-Specific Window functions #111359

Harley Acheson referenced a pull request that will close this issue

2023-08-24 21:34:31 +02:00