Fix filmstrip: keyboard shortcuts apply to wrong image

[vtyrtov]

Fixes #19775

Problem:
When the mouse cursor is over a thumbnail in the filmstrip (especially over overlay elements like stars or edges), keyboard shortcuts for rating, color labels, etc. were being applied to the currently open image in darkroom instead of the image under the cursor.

Root cause:
Keyboard events trigger spurious GDK_LEAVE_NOTIFY events with GDK_NOTIFY_ANCESTOR detail in GTK. The thumbnail's leave event handlers (_event_box_enter_leave, _event_btn_enter_leave, _event_star_leave, _event_main_leave) were resetting mouse_over_id to NO_IMGID when receiving these events, causing dt_act_on_get_images() to fall back to using active_images instead of the hovered image.

Solution:
Remove the mouse_over_id resets from thumbnail-level leave handlers. The proper place to reset mouse_over_id is in thumbtable's leave handler (_event_leave_notify in thumbtable.c), which correctly distinguishes between leaving the thumbnail for another thumbnail (GDK_NOTIFY_INFERIOR) and actually leaving the thumbtable area.

Changes:

• Removed mouse_over_id resets from _event_box_enter_leave, _event_btn_enter_leave, and _event_star_leave
• Removed _event_main_leave function and its signal connection entirely as it served no purpose after removing the mouse_over_id reset

[horazont]

From a quick test, it looks like that fixes it.

[TurboGit]

@dterrahe : I'd like you review on this if possible. TIA.

[TurboGit]

This fixes the issue on my side too.

[dterrahe]

I can't properly test this week, sorry. The thing to look out for is what happens when you move directly from hovering over a "gadget" within the thumbnail to outside the thumbnail. For example when the gadget (a star or something) is bordering the thumbnail or if the mouse move is so quick that there's no intermediate position where it is outside the gadget but still inside the thumbnail. In that case, does the thumbnail leave get called? Does everything reset correctly?

In gtk4 the enter/leave stuff is rejigged so that (I think) the outermost object always gets notified when you leave, but in gtk3 I remember we had issues around this.

[vtyrtov]

If you move the cursor from the "stars" from left to right in the reject of another image, the ID does not change. Working with it.

I haven't found any other errors yet.

[horazont]

Another option would be to get rid of the 1px of space between the thumbs (or make that space part of the thumb widget somehow), wouldn't it?

[vtyrtov]

Another option would be to get rid of the 1px of space between the thumbs (or make that space part of the thumb widget somehow), wouldn't it?

There's a different problem - the overlays don't cover the thumbnail entirely. But there is no gap between the thumbnail (this is indicated by the correct operation of the tooltip). They'll make a commit soon, which I haven't identified any problems on yet (I'm testing at the moment)

[vtyrtov]

Updated the fix to handle additional edge cases:

1. Removed !thumb->mouse_over conditions from all enter event handlers (_event_box_enter_leave, _event_image_enter_leave, _event_star_enter). This ensures mouse_over_id is updated on every enter event, fixing issues with fast transitions between overlay elements of different thumbnails.

2. Added mouse_over_id update to _event_btn_enter_leave enter handler. This handles transitions to overlay buttons (reject, color labels, etc.) that weren't being tracked before.

3. Added proper cleanup in _event_btn_enter_leave leave handler to reset darktable.control->element when leaving the reject button, ensuring hover state is cleared correctly.

These changes address the feedback about fast mouse movements between overlay elements while maintaining the original fix for keyboard shortcuts.

[TurboGit]

I'm a bit uneasy for this in 5.4. The issue it fixes is not that bad and I fear some possible regression with this as it touches a delicate part.

[vtyrtov]

Yes, there's a vicious circle - fixing one problem brings back another. If the move to gtk4 is just around the corner, then let it stay as it is?

[TurboGit]

Yes, either that or merge this early in 5.6 cycle to at least get good field testing. You're call on this, if you prefer closing this let me know.

[vtyrtov]

merge this early in 5.6 cycle to at least get good field testing

Let's do this