01:42 karenw: Can you have multiple pointers or keyboards (from multiple wl_seats) focusing the same window?
01:50 FreeFull: I believe you can
01:59 karenw: Good good, not too difficult to make Window.Focus a set instead of a singleton per-window.
02:08 karenw: Window needing to be able to access cursors to change them breaks the otherwise neat seperation between 'window' and 'seat' I have. But api bends to the needs of reality, not the other way around.
02:32 kode54: DemiMarie: yes, input events exactly over Xwayland windows. Easily observed with XEyes
02:59 karenw: Oh yeah, xeyes is super cursed on (x)wayland
03:00 karenw: I assume a 'wleyes' is impossible without compositor-specific protocol?
03:09 emersion: correct
03:15 soreau:mumbles something about pointer-lock
03:24 karenw: So. wl_cursor vs wl_shape gives me different sized cursors. What's the correct size to pass to wl_cursor other than "Try XCURSOR_SIZE in the environment, then guess just 24 arbitarily"
03:24 karenw: *wp_cursor_shape
03:32 DemiMarie: emersion: Would creating a fullscreen transparent X11 window be a reasonable workaround?
03:33 DemiMarie: These are legacy GTK3 applications, and they will eventually be replaced with something using layer-shell but that will take quite a while because the new UX will be completely different.
03:44 soreau: DemiMarie: if you do the fs transparent thing, you'd probably want to propagate the click to the surface beneath the transparent surface
05:01 DemiMarie: soreau: why is that?
05:04 soreau: because I expect that the transparent surface would need to 'accept' the click and the user would expect whatever they clicked on (like a wl surface) to be clicked on where they clicked (beneath the transparent surface)
05:07 soreau: as opposed to needing to click twice
05:08 soreau: the other thing it might break is surface-focus-follows-mouse
05:10 soreau: I'd probably just try to make it so pointer leave event closes the menu
05:11 soreau: but you might consider searching for or filing an issue, this is likely a problem in many compositors
08:31 MrCooper: DemiMarie: because Xwayland is mostly a normal Wayland client and receives input only through its Wayland surfaces
08:32 DemiMarie: MrCooper: Should there be a special protocol that allows Xwayland to grab the mouse, as there already is for the keyboard?
08:34 davidre: xwayland has code to use pointer locks but I dont know what on the X side triggers it
08:34 ofourdan: Such a protocl would be trivial, but unlikely to be accepted/adopted
08:34 ofourdan: (pointer locks is something different and disabled as soon as pointer focus is lost anyway)
08:36 DemiMarie: MrCooper: This causes bugs for OpenJDK too :(
08:36 DemiMarie: Generally anything involving X11 popups will be affected.
08:38 DemiMarie: Is there anything that compositors could do to improve the situation?
08:38 ofourdan: I don't think there's anything the compositor (nor Xwayland) can do without a dedicated protocol
08:39 DemiMarie: Would such a dedicated protocol be usable?
08:39 DemiMarie: And is it a good idea?
08:40 ofourdan: usable, that would be the purpose, a good idea, depends who you ask I presume, I think not really
08:41 DemiMarie: why?
08:41 DemiMarie: worth noting that the UX person at my company considered this to be a (rather serious) bug
08:42 ofourdan: because for many, Wayland not having active device grabs is a feature, so adding such a protocol would be a regression in tha regard.
08:43 ofourdan: that's why I say it depends who you ask, everyone has the right to have an opinion ;-)
08:45 ofourdan: fwiw, in mutter/GNOME SHell the keyboard grab protocol support is limited exclusively to Xwayland and is disabled by default, and enabled on a per X11 app basis using a mechanism of allow/deny lists.
08:46 ofourdan: the only reason I added the keyboard grabs was to fix a blocking bug with some X11 app, thypically O-R windows issuing a keyboard grab to read a password
08:46 ofourdan: *typically
08:46 ofourdan: (as O-R windows should not get input focus from the X11 WM, and without active device grabs these would not work at all under Xwayland)
08:47 ofourdan: I don't think the lack of pointer grabs is actually blocking or preventing an application from working entirely.
08:48 ofourdan: it has some unpleasant side effects, like popup menus in Motif apps for example which remain on screen when clicking outside of the window, but that's not blocking.
08:55 ofourdan: and, as you said, device grabs work between X11 apps in Xwayland, just not with Wayland native ones.
08:57 DemiMarie: Unfortunately for Qubes OS users, three of these applications are ones users use all the time. One is used for updates, another for system management and another for device management.
09:00 davidre: Could you port them to not be wayland apps?
09:00 davidre: *not be x11 apps
09:00 davidre: and wayland instead
09:05 MrCooper: indeed, since you mentioned GTK3, which has a Wayland backend
09:07 davidre: afaiu these would be trusted in qubes so wayland should be allowed for them?
09:07 MrCooper: FWIW, if any new protocol, I'd prefer a narrow one specifically for this use case (e.g. just give Xwayland the information that the user clicked somewhere outside of its surfaces), not a broad one like "pass all mouse input to Xwayland all the time"
09:07 DemiMarie: David Redondo: the technical problem is that Wayland doesn't support absolute window position which is a requirement here
09:07 DemiMarie: these are popup menus that appear when the user clicks on a tray icon
09:08 davidre: Is that using StatusNotifier?
09:08 DemiMarie: Right now it uses XEmbed but that is the easy part to change. The hard part is that the menus are far too complex for dbusmenu to be viable.
09:08 davidre: Ok that would have been my next question^^
09:09 MrCooper: DemiMarie: beware of the X Y problem, your question was assuming one specific solution for the issue
09:10 DemiMarie: MrCooper: the underlying problem being solved is "how do I keep the current UX without being stuck with the deprecated X11 session in KDE"
09:10 DemiMarie: replacing the UI with something more Wayland-friendly will take a year
09:11 MrCooper: right, and there's a few steps before we get to "Xwayland needs to receive all mouse input all the time"
09:11 ofourdan: ^_~
09:12 davidre: Demi: Hack idea, on StatusNotifierItem.ShowMenu(int x, inty) map a transparent surface the size of the screen and draw your menu at x, y
09:13 DemiMarie: David Redondo: I like that. I guess that would be combined with telling GTK to not draw decorations and telling the compositor to not draw any either?
09:14 ofourdan: wasn't there something about fullscreen transparent surfaces denined input events as a security measure ot something? Ot did I make that up…
09:14 DemiMarie: David Redondo: will that be off by the size of the titlebar?
09:15 davidre: I have no experience in gtk so I cannot tell but KWin will not draw decorations if you dont create xdg-decoration-object
09:16 davidre: Which titlebar?
09:16 DemiMarie: Big bar drawn across top/bottom of screen.
09:16 DemiMarie: Not sure what its formal name is
09:19 davidre: I cannot tell right now
09:19 davidre: Just had the idea when I saw these x, y arguments in the method, which probably are usefull on x11
09:19 davidre: not sure if those produce any good value on wayland
09:20 DemiMarie: David Redondo: thanks for the help
09:45 davidre: Demi: I checked the coordinates and they seem to be the actual coordinates with a bottom panel
09:45 DemiMarie: David Redondo: thanks!
10:50 wlb: weston Merge request !1652 opened by () backend-drm: Add support for YUV plane color properties https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1652 [Colour management], [DRM/KMS backend]