Skip to content

port to GTK4

Anton Lazarev requested to merge antonok/libcall-ui:gtk4 into main

Closes #2 (closed)

Finally ready for review! I've tried to keep my commits limited to individual changes as much as possible here, with context and related links in commit messages wherever relevant.

Feature parity

As far as I've been able to observe, this port achieves full feature parity with the GTK3 version, with one exception:

  • The customized Tab-focus ordering in CuiDialpad was removed altogether (see final commit). There's an extremely concise mention of the recommended alternative approach in the GTK3 docs deprecation notice for focus-chain, but as noted in the commit message, there's practically no information about how to pull off the changes. The mentioned alternative also doesn't exist in GTK4. Options I've considered:
    • the GtkWidget::move-focus signal. The API looks reasonable enough, but I wasn't able to observe it firing in response to any interaction.
    • the GtkEventControllerFocus controller. It works but doesn't indicate the direction of focus changes and thus would require reimplementing a separate focus-state-transition tracking mechanism otherwise. I haven't pursued this approach since it seems like it'd add significant complexity, be fragile, and have a high probability of not handling edge cases correctly.
    • listening to changes on the GtkWidget::has-focus property. Same drawbacks as GtkEventControllerFocus since no direction is specified.
    • After much searching, I found GNOME/gtk#1430 (comment 1637607), which describes how a focus chain was re-implemented in GTK4 for gnome-text-editor. It's commendable, but I'm not convinced the benefits are worth the additional code in this case?

Anyways, given all the difficulties involved in the above, my impression is that custom focus handling is not a well-supported use case in GTK4 and it's probably best to drop it altogether. But I'd like to hear from maintainers here first.

Deprecations

There's 1 deprecation warning when building because CuiDemoWindow still uses a MessageDialog. I haven't touched it in this PR since there's already a lot going on, but it should probably be ported to AlertDialog as a followup.

Misc

The tests work totally fine on my machine but somehow CI here doesn't seem to like them. The error messages aren't particularly helpful either. I'm open to suggestions.

1/3 keypad  FAIL            0.43s   killed by signal 5 SIGTRAP
>>> G_DEBUG=gc-friendly,fatal-warnings NO_AT_BRIDGE=1 MALLOC_PERTURB_=143 MALLOC_CHECK_=2 /builds/antonok/libcall-ui/_build/tests/keypad
2/3 dialpad FAIL            0.44s   killed by signal 5 SIGTRAP
>>> MALLOC_CHECK_=2 G_DEBUG=gc-friendly,fatal-warnings NO_AT_BRIDGE=1 MALLOC_PERTURB_=54 /builds/antonok/libcall-ui/_build/tests/dialpad
3/3 display FAIL            0.45s   killed by signal 5 SIGTRAP
>>> G_DEBUG=gc-friendly,fatal-warnings NO_AT_BRIDGE=1 MALLOC_PERTURB_=87 MALLOC_CHECK_=2 /builds/antonok/libcall-ui/_build/tests/display
Edited by Anton Lazarev

Merge request reports