ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
rgallaispou has joined #wayland
feaneron has quit [Quit: feaneron]
feaneron has joined #wayland
rgallaispou has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
feaneron has quit [Quit: feaneron]
feaneron has joined #wayland
feaneron has quit [Quit: feaneron]
feaneron has joined #wayland
feaneron has quit [Quit: feaneron]
feaneron has joined #wayland
Guest1156 has quit []
karenw has joined #wayland
feaneron has quit [Quit: feaneron]
feaneron has joined #wayland
<karenw>
Can you have multiple pointers or keyboards (from multiple wl_seats) focusing the same window?
<FreeFull>
I believe you can
karenw has quit [Quit: Konversation terminated!]
karenw has joined #wayland
karenw has quit []
karenw has joined #wayland
karenw has quit []
karenw has joined #wayland
<karenw>
Good good, not too difficult to make Window.Focus a set instead of a singleton per-window.
<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.
<kode54>
DemiMarie: yes, input events exactly over Xwayland windows. Easily observed with XEyes
kts has joined #wayland
feaneron has quit [Quit: feaneron]
feaneron has joined #wayland
kts has quit [Quit: Konversation terminated!]
feaneron has quit [Quit: feaneron]
feaneron has joined #wayland
<karenw>
Oh yeah, xeyes is super cursed on (x)wayland
<karenw>
I assume a 'wleyes' is impossible without compositor-specific protocol?
<emersion>
correct
* soreau
mumbles something about pointer-lock
Arnavion has quit [Remote host closed the connection]
Arnavion has joined #wayland
<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"
<karenw>
*wp_cursor_shape
garnacho has quit [Ping timeout: 480 seconds]
<DemiMarie>
emersion: Would creating a fullscreen transparent X11 window be a reasonable workaround?
IMTheNachoMan has joined #wayland
<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.
<soreau>
DemiMarie: if you do the fs transparent thing, you'd probably want to propagate the click to the surface beneath the transparent surface
nerdopolis has quit [Ping timeout: 480 seconds]
abhimanyu has joined #wayland
feaneron_ has quit [Ping timeout: 480 seconds]
karenw has quit [Ping timeout: 480 seconds]
riteo has quit [Ping timeout: 480 seconds]
vincejv- has joined #wayland
vincejv- has quit []
vincejv has quit [Ping timeout: 480 seconds]
mxz_ has joined #wayland
vincejv has joined #wayland
mxz has quit [Ping timeout: 480 seconds]
mxz__ has quit [Ping timeout: 480 seconds]
mxz_ is now known as mxz
<DemiMarie>
soreau: why is that?
<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)
kts has joined #wayland
<soreau>
as opposed to needing to click twice
<soreau>
the other thing it might break is surface-focus-follows-mouse
<soreau>
I'd probably just try to make it so pointer leave event closes the menu
<soreau>
but you might consider searching for or filing an issue, this is likely a problem in many compositors
kts has quit [Ping timeout: 480 seconds]
feaneron has quit [Quit: feaneron]
feaneron has joined #wayland
feaneron has quit []
feaneron has joined #wayland
coldfeet has joined #wayland
feaneron has quit [Quit: feaneron]
feaneron has joined #wayland
glennk has joined #wayland
feaneron has quit [Quit: feaneron]
feaneron has joined #wayland
coldfeet has quit [Remote host closed the connection]
<MrCooper>
DemiMarie: because Xwayland is mostly a normal Wayland client and receives input only through its Wayland surfaces
<DemiMarie>
MrCooper: Should there be a special protocol that allows Xwayland to grab the mouse, as there already is for the keyboard?
kts has quit [Quit: Konversation terminated!]
<davidre>
xwayland has code to use pointer locks but I dont know what on the X side triggers it
<ofourdan>
Such a protocl would be trivial, but unlikely to be accepted/adopted
<ofourdan>
(pointer locks is something different and disabled as soon as pointer focus is lost anyway)
<DemiMarie>
MrCooper: This causes bugs for OpenJDK too :(
garnacho has joined #wayland
<DemiMarie>
Generally anything involving X11 popups will be affected.
<DemiMarie>
Is there anything that compositors could do to improve the situation?
<ofourdan>
I don't think there's anything the compositor (nor Xwayland) can do without a dedicated protocol
<DemiMarie>
Would such a dedicated protocol be usable?
<DemiMarie>
And is it a good idea?
<ofourdan>
usable, that would be the purpose, a good idea, depends who you ask I presume, I think not really
<DemiMarie>
why?
<DemiMarie>
worth noting that the UX person at my company considered this to be a (rather serious) bug
<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.
<ofourdan>
that's why I say it depends who you ask, everyone has the right to have an opinion ;-)
<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.
<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
<ofourdan>
*typically
<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)
<ofourdan>
I don't think the lack of pointer grabs is actually blocking or preventing an application from working entirely.
<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.
<ofourdan>
and, as you said, device grabs work between X11 apps in Xwayland, just not with Wayland native ones.
sally has quit [Quit: sally]
<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.
<davidre>
Could you port them to not be wayland apps?
<davidre>
*not be x11 apps
<davidre>
and wayland instead
sally has joined #wayland
<MrCooper>
indeed, since you mentioned GTK3, which has a Wayland backend
vincejv has quit [Remote host closed the connection]
<davidre>
afaiu these would be trusted in qubes so wayland should be allowed for them?
<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"
<DemiMarie>
David Redondo: the technical problem is that Wayland doesn't support absolute window position which is a requirement here
<DemiMarie>
these are popup menus that appear when the user clicks on a tray icon
<davidre>
Is that using StatusNotifier?
<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.
<davidre>
Ok that would have been my next question^^
rgallaispou has joined #wayland
<MrCooper>
DemiMarie: beware of the X Y problem, your question was assuming one specific solution for the issue
<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"
<DemiMarie>
replacing the UI with something more Wayland-friendly will take a year
<MrCooper>
right, and there's a few steps before we get to "Xwayland needs to receive all mouse input all the time"
<ofourdan>
^_~
<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
<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?
<ofourdan>
wasn't there something about fullscreen transparent surfaces denined input events as a security measure ot something? Ot did I make that up…
<DemiMarie>
David Redondo: will that be off by the size of the titlebar?
FreeFull has quit [Quit: Just a quick reboot]
FreeFull has joined #wayland
<davidre>
I have no experience in gtk so I cannot tell but KWin will not draw decorations if you dont create xdg-decoration-object
<davidre>
Which titlebar?
<DemiMarie>
Big bar drawn across top/bottom of screen.
<DemiMarie>
Not sure what its formal name is
<davidre>
I cannot tell right now
<davidre>
Just had the idea when I saw these x, y arguments in the method, which probably are usefull on x11
<davidre>
not sure if those produce any good value on wayland
<DemiMarie>
David Redondo: thanks for the help
kts has joined #wayland
KamilAronowski[m] has joined #wayland
feaneron has quit [Read error: Connection reset by peer]
feaneron has joined #wayland
rasterman has joined #wayland
cyrinux has quit []
cyrinux has joined #wayland
<davidre>
Demi: I checked the coordinates and they seem to be the actual coordinates with a bottom panel