08:19 wlb: wayland-protocols Issue #194 closed \o/ (RFC: new category for legacy compatibility extensions https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/194)
08:21 ifreund: :)
11:27 pq: If destructor request creates a new object while destroyng the old one, can one use that with a proxy-wrapper so that the events on the new object have the correct event queue?
11:27 pq: I think not, because proxy-wrapper cannot be destroyed like that.
11:29 pq: Luckily in the color-management case, one can make a proxy-wrapper from the global-bound object to avoid this.
12:00 wlb: wayland-protocols Issue #196 opened by Julian Orth (mahkoh) Different tablet behaviors of compositors https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/196
12:19 wlb: wayland-protocols Merge request !311 opened by Poly (PolyMeilex) Fix some trivial typos https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/311
12:21 wlb: wayland-protocols/main: PolyMeilex * Fix some trivial typos https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/9bfb27f0a475 stable/linux-dmabuf/linux-dmabuf-v1.xml stable/xdg-shell/xdg-shell.xml staging/drm-lease/drm-lease-v1.xml tests/replace.py unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
12:21 wlb: wayland-protocols Merge request !311 merged \o/ (Fix some trivial typos https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/311)
12:36 pq: I have downgraded my Gitlab roles, in Wayland group in particular, to better reflect the position where I want to be.
12:38 pq: I have also turned down a notch my Gitlab notifications to become less easily distracted, IOW less likely to pop in random threads.
14:04 wlb: weston Issue #904 opened by Sebastian Urban (surban) How to avoid application window obstruction by input panel (on-screen keyboard)? https://gitlab.freedesktop.org/wayland/weston/-/issues/904
19:06 colinmarc: If I want to support FPS games that "lock" the cursor to the center of the screen, which protocol do I need to implement in my compositor?
19:06 colinmarc: or is that part of the basic wl_pointer stuff and I'm missing it?
19:16 vyivel: colinmarc: pointer-constraints-unstable-v1 and most probably relative-pointer-unstable-v1
21:46 UndeadLeech: I'm opening a subsurface under the pointer in my client, if the pointer isn't moved, then the first button click still goes to the subsurface behind it. Does anyone know if this is an issue with Sway, or if I'm maybe doing something wrong in my client?
21:46 kennylevinsen: sway recomputes focus when you move the cursor
21:47 UndeadLeech: So it's a Sway issue then?
21:47 UndeadLeech: Button down also seems to update focus, it's just really unfortunate opening a subsurface doesn't update it.
21:51 kennylevinsen: I wouldn't expect the focus to immediately change when the subsurface appears, but I imagine we should refocus so click goes to whatever is under the cursor at that point in time
21:51 UndeadLeech: From what I recall, there's no way to force the compositor to recompute either, right? No tricks to make it update?
21:51 kennylevinsen: Although others might weigh in as to what to expect when a subsurface sneaks under the cursor, it's *slightly* unusual
21:52 kennylevinsen: No, there isn't
21:52 UndeadLeech: I wouldn't consider it that unusual. I'm using subsurfaces to render an application with multiple layers. Seems like something not super uncommon.
21:52 kennylevinsen: What's the use-case?
21:53 kennylevinsen: Using multiple subsurfaces is one thing, relying on pointer focus moving between said subsurfaces instantaneously another
21:55 UndeadLeech: https://xn--z7x.xn--6frz82g/tmp/f/bX.mp4
21:55 UndeadLeech: My primary focus is touch input, so I guess it doesn't really matter. But my two buttons are just inconveniently placed right above each other.
21:56 UndeadLeech: It doesn't feel like I'm doing anything wrong. Feel free to let me know if you disagree.
22:18 kennylevinsen: UndeadLeech: Hmm no that looks reasonable that we should recompute focus on first button click before sending it, so that it hits the new "plus" button
22:19 kennylevinsen: not sure if we'd bother recomputing focus on every surface change though, so it's likely it'll be remain delayed till first user input
22:20 UndeadLeech: Yeah I don't really care if it's recomputed as soon as the surface comes up. I just wanna be able to spam left button to open a bunch of tabs quickly.
22:21 UndeadLeech: Want me to open an issue with the video on GH assuming it's not tracked yet?
22:22 kennylevinsen: Yeah, please do so we don't forget
22:29 UndeadLeech: Thanks for the help. I got a bit confused since Smithay seems to have the same issue.
22:34 kennylevinsen: (If it affects many compositors, one workaround would be to use empty input regions for the subsurfaces and handle the input through the top-level)
22:35 UndeadLeech: Yeah I guess that would be an option if I cared much about pointer events. But since this is supposed to be a mobile browser it's mostly a testing thing.
22:35 UndeadLeech: And fingers tend to be much less precise.