gtk4-prep: event controllers - #21659
Conversation
b8a350c to
676138c
Compare
|
Soon I'll start using this PR daily for testing. |
|
Found a bug, you cannot define a new shortcut using the keyboard icon top-right.
|
|
Dragging the visible area in the navigation panel does not work: 
|
|
Another one, selecting any algorithm on the |
|
Fixes:
|
93b61f8 to
d7d545d
Compare
|
@Arecsu : There is a conflict resolution needed. Also, I would propose to merge this just after the conflict resolution is fixed to gain more field testing. On my side I have not discovered other issues. Ok? |
Restore the scroll event masks that were removed when cleaning up
gtk_widget_add_events() calls during the event controller conversion.
Both widgets still use the old g_signal_connect('scroll-event', ...)
for event forwarding (colorequal forwards to notebook/sliders,
tonequal controls propagation), which requires GDK_SCROLL_MASK in
the widget's event mask to function.
- Properly indent closing brace in tonecurve.c secondary-button handler - Add missing newline before closing brace in colorzones.c - Remove stray duplicate void gui_init line in map_locations.c
Update copyright end-year to 2026 in files touched by event controller conversion that still had outdated ranges.
…s/release callbacks
…m signature change
d7d545d to
88e6de8
Compare
|
@TurboGit solved. I've also solved the last bug I could find in darkroom second window, where the touchpad two-pinch zoom gesture wouldn't work. I've matched the same interaction from darkroom main image area, which works great already. |
|
There's going to be some PRs that will need to adapt their code to event controllers for sure. In any case, feel free to report problems. At least from current |
PRs still carrying old-style GTK event code need adaptationNeed conversion (carry old-style event code in converted files):
Superseded
Might be rebase only (touch converted files, add no event code): #21661, #21512, #21648, #21620, #21107, #21255, #21590, #21534, #21319, #21252, #21368, #21715, #21024, #21033 — no old-style event code in their diffs; just conflict resolution. Some things could explode. Like #21677 which found a bug related to this PR. #21718 should solve it in the meantime. There might be more PRs in the way which I'm not accounting here. This is the analysis that I was able to do for the time being. |
|
Ah sorry, I didn't have time before; I see it has been merged and there have been more fixes since. Does this help? Panel Review — base=4a8a1cfd90 (gtk4/event-controllers-all)Important (accepted, severity medium)
Minor (accepted, severity low)
Contested (reviewers held positions — you decide)
UnresolvedNone — every issue reached at least one peer-review pass with all three seats engaged. Rejected (raised then dropped)
Note on the four rejections above: they all assert that a GTK3 symbol "is removed in GTK4". That is true of GTK4, but this branch still builds against GTK3 only ( Merged
|
|
This definitely helps but there have been many PRs and commits addressing some of the things here AFAIK. If you can run the same checks you've done against all gtk4-prep titled commits from master, that would be neat |
|
Yes, running for 21742. I'll go to sleep afterwards, but can do the rest. Mention me on an issue at any time if you want a review; if the budget allows, I'll do it. |
|
Thank you @kofa73. I'm currently running all these suggestions over my workflow, testing, debugging, cleaning up things. I'm doing this by merging all my PRs that are still open because some of them already address points in the write-ups |
4 participants
Huge PR. Needs further testing to see if interactions, keyboard events, mouse, trackpad, scrolls, anything in the UI UX responds ok, across Linux, macOS, Windows.
I've been testing this, polishing code, fixing bugs across the commits. So far so good. But I'm pretty sure I might be missing something, somewhere, deep down a weird module used by a small fraction of people, or could be even obvious issues which I didn't notice.
Mostly mechanical changes, but so many of them had to be made for their particular context. Some code clean up here and there, helpers, macros, but mostly porting to be gtk4 compatible.
Given all changes across files are somewhat related to one another, I concluded that splitting this into many PRs will be more of a time and effort block than anything else. A bug that might happen to a particular module might have its solution (or bug) related to a similar code path somewhere else. So, that's my logic for having this PR in one go.
I need help in testing this!
Skipped in this PR
Focus events (
focus-in-event/focus-out-event, ~30 callers):GtkEventControllerFocusdoesn't exist in GTK 3.24 — it's a GTK4-only class. We can't convert these until we actually switch to GTK4, so they stay asg_signal_connectfor now and will become a mechanical find-and-replace at migration time.Dialog enter key (
dt_handle_dialog_enter, ~6 callers): These bind Enter to "ok" in modal dialogs usingg_signal_connect(dialog, "key-press-event", ...). On GTK4,GtkDialoghandles this natively, so the workaround can simply be deleted — no conversion needed. It's deferred because it touches the same foundation layer ingtk.cthat's being left alone until the switch.Foundation infrastructure in gtk.c itself (~33 signals): These are the remaining event signals inside
src/gui/gtk.cthat cover low-level UI — the panel resize handles (12 signals), notebook tab reordering (3), scrollable containers, toast/log widgets, and most importantly the internals ofdt_gui_connect_click()anddt_gui_connect_double_click()themselves. These can't be converted on GTK 3.24 because they involve window-level event propagation, scrolled-window interaction, and the gesture controller creation code that everything else depends on. They stay as-is until the actual GTK4 switch, when the whole helper layer can be replaced, I guess, with native GTK4 APIs.Related: #20433