[GTK4] Manage propagation for gesture events and fix popup menus #1984
Conversation
|
Left is how it currently looks like, right is how it's supposed to look like. The current menu is the default one provided by GTK and not the one that's created in Snippet 122.
|
bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Widget.java
Outdated
Show resolved
Hide resolved
bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Control.java
Show resolved
Hide resolved
Test Results 408 files - 137 408 suites - 137 18m 16s ⏱️ - 11m 12s Results for commit b083dda. ± Comparison against base commit e218c17. This pull request removes 37 tests.♻️ This comment has been updated with latest results. |
|
I tried running this PR and it crashed with Do you experience that ? |
Yes. Locally I've adapted And just as a general update: I'll plan on creating a separate PR to properly implement the event cancellation, because the current approach in this PR of always consuming the event doesn't cover all cases. In short: If no menu is set, the default menu should be used. At least that's how it currently works with GTK3 and something you can see in the snippet if you comment out the call to Conversly, if the event is never consumed, you get both the default menu and the SWT menu on top of each other... |
ptziegler
changed the title
|
@akurtakov I've tried to find another way to produce a "bubbling event", but so far without success. So in the end, I've combined everything in a single commit. For testing, I've used Snippet 122 with and without a menu, together with #1990. |
For e.g. the text widget, a default pop-up menu if provided by GTK and activated, unless a custom menu is set within SWT. To avoid both menus being shown at the same time, the event must be consumed when showing the SWT menu. In GTK3, this is done by returning TRUE in the callback method, which is no longer possible in GTK4. Instead, the event needs to be marked as "claimed" via gtk_gesture_set_sequence_state(), to prevent other, native listeners from processing it as well. To do so, the gtk_gesture_press_event() and gtk_gesture_release_event() have been adapted to now return an integer, which may be one of the following values: - GTK_EVENT_SEQUENCE_NONE - GTK_EVENT_SEQUENCE_CLAIMED - GTK_EVENT_SEQUENCE_DENIED For example, the value should be GTK_EVENT_SEQUENCE_CLAIMED after the menu is shown. Note: It is not possible to always claim an event as "claimed", as it would then prevent the default value from being shown at all, even if no SWT menu is set. Additionally, the check for whether a menu can be shown has been inverted ((state & MENU) != 0), to match the GTK3 logic. Because this bit is always set, this effectively stops all SWT menus from being shown.
|
This is clear improvement to the current state thus pushing. Further improvements (if needed) should be handled separately. |
2 participants
For e.g. the text widget, a default pop-up menu if provided by GTK and
activated, unless a custom menu is set within SWT. To avoid both menus
being shown at the same time, the event must be consumed when showing
the SWT menu.
In GTK3, this is done by returning TRUE in the callback method, which is
no longer possible in GTK4. Instead, the event needs to be marked as
"claimed" via gtk_gesture_set_sequence_state(), to prevent other, native
listeners from processing it as well.
To do so, the gtk_gesture_press_event() and gtk_gesture_release_event()
have been adapted to now return an integer, which may be one of the
following values:
For example, the value should be GTK_EVENT_SEQUENCE_CLAIMED after the
menu is shown.
Note: It is not possible to always claim an event as "claimed", as it
would then prevent the default value from being shown at all, even if no
SWT menu is set.
Additionally, the check for whether a menu can be shown has been
inverted ((state & MENU) != 0), to match the GTK3 logic. Because this
bit is always set, this effectively stops all SWT menus from being
shown.