Popover input on macOS

[Paul_Emsley]

Hi @lb90,
Now that GTK4 work works me, I would like it to work for others (my users and other Mac-using GTK4 users).
What happens next? How does the fix get added to 4.12.x? It seems to me that the complete reversion of gdk/surface: Handle clicks outside client surfaces (e7f798dc) · Commits · GNOME / gtk · GitLab is not what is needed for GTK4 - presumably it was useful for some (non-Mac-using) people. So e7f798dc needs to be reworked so that it only gets invoked on X11 infrastructures.
How does that come about? Will you do it? Should I? @carlosg? Someone else?
Thanks,
Paul.

[garnacho (Carlos Garnacho)]

Hi,

I think a good start is a GTK issue explaining how does that commit regress the macOS backend. There were indeed reasons to make that commit, and I slightly suspect the reasons for it to break is that the macOS backend is not generating crossing events with the expected mode here.

But I’m much less acquainted with the macOS backend than with the Wayland/X11 ones, so it would be great to get a breakdown of the failure. Or perhaps there is such issue and I missed it…?

Cheers,
Carlos

[lb90]

Hi @Paul_Emsley, @garnacho! I have a plan for that, but I’d like to hear @garnacho opinion first

Listening for crossing events is a great way of knowing when a click is made outside of a (grabbing) autohide surface, but we’ve encountered two practical issues:

1. There seems to be a problem in XOrg / XI2 where crossing events are not generated if a surface takes an explicit grab while a button is down. This is causing activation issues in X11: Context menus in KGX and g-t-e fail to activate actions on X11 (#5712) · Issues · GNOME / gtk · GitLab
2. The macOS backend doesn’t generate crossing events correctly on Ventura and later. This was initially reported for GTK3, but later confirmed to apply for GTK4 as well: widgets not reacting to mouse hover/click on macOS Ventura (#5305) · Issues · GNOME / gtk · GitLab

While 2) may be fixed, it’s quite unlikely for 1) to ever be fixed, IMHO. So I was thinking about something different: stop listening for crossing events and instead replicate what the Wayland backend does. GDK/Wayland is notified of external clicks via xdg_popup.done, but other GDK backends can do the same

For example, GDK/X11 can create an input-only Window and grant it an owner-events grab. Upon receiving a button press event on the input-only Window we can hide the popover. Also note that implementing such support is just an enhancement! if a GDK backend does nothing, popovers will not be closed when clicking / activating other applications, and that’s fine

[garnacho (Carlos Garnacho)]

@lb90

There seems to be a problem in XOrg / XI2 where crossing events are not generated if a surface takes an explicit grab while a button is down. This is causing activation issues in X11: Context menus in KGX and g-t-e fail to activate actions on X11 (#5712) · Issues · GNOME / gtk · GitLab

Hmm, I see an early break in XI_Enter/Leave handling at gdk/x11 that might be involved in not seeing any GDK crossing event whatsoever. I would certainly expect one or more crossing events in those circumstances (e.g. different modes, also due to the exchange between implicit and active grabs).

@lb90

While 2) may be fixed, it’s quite unlikely for 1) to ever be fixed, IMHO. So I was thinking about something different: stop listening for crossing events and instead replicate what the Wayland backend does. GDK/Wayland is notified of external clicks via xdg_popup.done, and other GDK backends are able to replicate that.

I think making the GDK API boundary resemble closer the Wayland higher-level semantics is only wise :). This might be a detail better hidden from the upper layers. Although if the issue happens in GTK3 too, it might require a different approach there.