gtk4-prep: fix color picker shortcuts and double-press on hold keys - #21733
gtk4-prep: fix color picker shortcuts and double-press on hold keys#21733Arecsu wants to merge 3 commits into
Conversation
Arecsu
changed the title
… buttons The gtk4-prep migration replaced the picker buttons' GObject button-press-event handler with a CAPTURE-phase GtkGestureMultiPress that claims the event sequence (the button's own internal bubble-phase gesture would otherwise toggle it a second time). Shortcut activation however still goes through dt_action_def_toggle, whose generic processor (_action_process_toggle) synthesizes GObject button-press-event signals: those only reach the widget class handler (bubble-phase controllers) and carry no device, so they can never trigger the CAPTURE-phase gesture -- picker shortcuts bound to standalone toggle buttons (e.g. AgX 'auto tune levels') silently stopped working. Give standalone picker buttons their own action definition (like bauhaus widgets have dt_action_def_bauhaus) whose process calls the same shared entry as real clicks, so shortcuts reach the picker directly without event synthesis. Update the five modules that define standalone picker buttons (AgX, channel mixer RGB, negadoctor, tone curve) to use it. Real clicks still go through the CAPTURE gesture, which now also passes the clicked button through so a secondary click still switches to area mode.
cd8826b to
0618c15
Compare
This is working on my side and it is broken with this PR. Or maybe we have different way to test this? |
This is interesting. I'm unable to remember if I tried this on macOS or Linux. Where did you test this? There was no way for me to get it working at all. Still, the "double A" key press would be completely eaten by it, as stated by one of the issue reporters. I tried my best to find a code that would make both scenarios to work but it looked really, really really bad honestly. Maybe it's incompetence on my side |
|
To test on my side without this PR:
This last step works on current master and fails with this PR. |
Testing on GNU/Linux. Maybe your |
Just to clarify, you need to press |
|
Ahhhhh I didn't know it worked that way, I was trying holding A in a 100% zoomed image and thinking it will move when my cursor was over the sidebar or something. I couldn't understand the purpose of it hahahaha I feel ashamed. Well that's really useful I would say. So, press A while using a color-picker tool for instance, and just moving the cursor or scroll wheel will do the trick right? |
Sure, it is also a needed feature when using the calibrating feature of "color calibration" module. In fact all modules displaying an overlay need this to be able to pan/zoom instead of interacting with the overlay.
Yes. |
|
Sorry about misunderstanding this one. Will check it tomorrow if possible, It's pretty late here. I will revert that commit but the mechanism to make "double A" shortcut to work will be sort of a mystery. If you have any clues or directions, it would be super useful! |
|
@Arecsu : Nothing urgent, and thanks for being so responsive. |
…efinition The earlier fix updated only the single-line dt_action_define_iop calls; multi-line call sites had the same latent shortcut bug. Borders (border and frame line color), watermark, the RGB levels pickers (macro) and the primary colorpicker lib button all used dt_action_def_toggle with a standalone toggle button, so picker shortcuts could not reach their CAPTURE-phase gesture either. Switch them all to dt_action_def_color_picker and drop the synthetic GdkEventButton construction in the shared callback: the picker logic only cares about ctrl/right-click, so pass those as explicit flags from the three activation paths (bauhaus quad, gesture, shortcut).
A key with a hold shortcut (e.g. the default 'a' = force pan/zoom/rotate with mouse) could never trigger a double/triple-press shortcut bound to the same key: every press re-engaged the hold and returned early, so the double/triple press detection never ran. Now the hold press is recorded in the shortcut state, and a fast consecutive press of the same key - while a double/triple press shortcut exists for it (checked via _shortcut_has_double_triple_press()) - falls through to the normal handling and is detected as a double/triple press instead of re-engaging the hold.
0618c15 to
a426666
Compare
Arecsu
changed the title
|
@TurboGit should be done by now, please test if possible with |
|
See https://www.githubstatus.com/ there is issues with GitHub runner at the moment. |
Yep, maybe they are migrating to gtk4 as well 🙂 |
|
Superseded by #21745 |
2 participants
1. Picker shortcuts
The gtk4-prep migration broke shortcuts for standalone picker buttons (like AgX's auto tune levels): click handling moved to a capture-phase gesture, and shortcuts (which synthesized fake
button-press-eventsignals) can't reach a capture-phase gesture. So shortcuts silently stopped triggering pickers while clicks kept working.Fix: standalone pickers now use their own action definition, like bauhaus widgets already did, calling the same code real clicks use. All twelve pickers share it, and the shared callback takes explicit ctrl/right-click flags instead of fabricating
GdkEvents.2. Double-press vs. hold on the same key
A key with a hold shortcut (default
a= force pan/zoom/rotate with mouse) could never trigger a double/triple-press shortcut bound to the same key: every press re-engaged the hold, so the double was never detected.Fix: the hold press is now recorded, and a fast consecutive press of the same key (when a double/triple shortcut exists for it) is detected as a double/triple press instead of re-engaging the hold. Both work now: hold
ato pan/zoom/rotate, tapatwice fora;double.Testing
b;double(AgX auto tune) and a customa;doublea(pan/zoom/rotate) andw(full preview) still behave normallyRelated: #15920 #20433
Fixes #21730
Fixes #21736