03:16 wlb: wayland Issue #511 opened by () wayland-util: There will be deviations when fixing floating point numbers using wl_fixed_from_double() https://gitlab.freedesktop.org/wayland/wayland/-/issues/511
08:21 ofourdan: DemiMarie: you mean an X11 window (running in Xwayland) or an Xwayland rootful instance running fullscreen?
08:23 ofourdan: anyways, a fullscreen X11 window will get mouse events (including button events) when the event occurs within the surface, just like any other Wayland surface. If the pointer sits outside of the Wayland surface, the events will not be routed to the Xwayland surface and it will not receive pointer events (there is no mechanism for grabbing input devices explicitely in Wayland)
08:25 ofourdan: (I'm thinking of multiple outputs here, the X11 window can be fullscreen on an output and the poitner on another)
08:39 ofourdan: fwiw, yes, it should be possible to make an X11 window fullscreen and have that get all pointer events, possibly using pointer locking, that's how most games work in Xwayland.
08:43 wlb: weston/main: Derek Foreman * desktop-shell: Make backgrounds fully opaque https://gitlab.freedesktop.org/wayland/weston/commit/264c205add27 clients/desktop-shell.c man/weston.ini.man weston.ini.in
08:43 ofourdan: (pointer locking and confinment, to be precise. Xwayland has some heuristics to translate the "confine_to" Window from XGrabPointer() to a pointer confine in Wayland)
08:43 wlb: weston Merge request !1659 merged \o/ (desktop-shell: Make backgrounds fully opaque https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1659)
09:22 DemiMarie: ofourdan: X11 window, yes. Will doing so have any unwanted side-effects if the window is transparent? This is a workaround for a GTK3 bug.
09:24 ofourdan: You're plannijng on mapping a transparent fullscreen X11 window to work aroung a gtk-3 bug? I think the potential side effects depend on how the compositor handles that.
09:24 ofourdan: (or rather, the X11 window manager in the compositor)
09:25 ofourdan: but that's easy to test, so best imho is to try with your compositor of choice and see how that behaves :)
09:25 ifreund: yeah, dont expect that kind of workaround to have perfectly portable UX, its a massive hack
09:25 wlb: weston Issue #982 opened by () Is there an easy way to support specific vendor formats in weston? https://gitlab.freedesktop.org/wayland/weston/-/issues/982
10:13 DemiMarie: ofourdan: the bug is that GTK relies on the globally active input model rather than focus change events.
10:18 DemiMarie: ifreund: Qubes OS has specific user experience requirements and not all of them are currently supported by Wayland without giant hacks. Getting the needed protocol extensions shipped in e.g. KWin would take years.
10:22 DemiMarie: I'm not using hacks because I like them, but because they are the only way I know of to ship something in a reasonable amount of time without regressing user experience.
10:24 DemiMarie: Has anyone else here had to ship ugly hacks to get something out in a decent amount of time?
10:24 DemiMarie: Wayland hacks specifically, like abusing a protocol for something it was not meant for.
10:26 emersion: nope. i just push for the proper solution (but also don't have deadlines)
10:32 DemiMarie: emersion: I do have deadlines 🙂
10:33 DemiMarie: And not enough resources to e.g. reimplement the whole UI multiple times, or fork a big compositor.
12:52 drakulix[m]: <DemiMarie> "Has anyone else here had to ship..." <- Does special-casing some layer-shell namespaces count? Otherwise, no not really. Worst case I namespace a draft-protocol, while slowly chipping away at upstream effords.
14:57 DemiMarie: <drakulix[m]> "Does special-casing some layer-..." <- I wonder if the difference is that I don't control the compositor side of things, meaning that private protocols aren't an option. I have to make do with what is upstream already.
14:58 DemiMarie: Also, this is all in the context of my work at porting Qubes OS's UI to Wayland.
15:23 Ermine: are you contracted to do so? re deadlines
15:24 DemiMarie: Ermine: That port is part of my paid job, and there is a deadline in the sense that the project can't wait for upstreaming of things that might never get upstreamed.
15:25 Ermine: ic
15:26 DemiMarie: In that situation, "do what you want" protocols like absolute positioning are extremely appealing.
15:27 DemiMarie: Ermine: what is yucky about this?
15:27 Ermine: Nothing, just was curious
15:31 d_ed[m]: <DemiMarie> "I wonder if the difference is..." <- Definitely doing wayland with existing clients is massively massively harder than doing any other wayland compositor work where it's a clean slate. I can sympathise with your position a lot more than maybe others.
15:31 d_ed[m]: But turning that into something constructive that wins over compositor devs is still a challenge.
15:31 d_ed[m]: I don't think discussing in the abstract helps too much
15:33 DemiMarie: d_ed: That's fair. In this case the actual need would be fulfilled by ext-tray-v1 combined with support for out of process plugins in all panels.
15:34 d_ed[m]: ack, I did promise to look into that properly and comment on it
15:34 DemiMarie: Thank you.
15:34 DemiMarie: UI consistency is not an issue here because the Qubes OS UI is deliberately different than that of the desktop environment.
15:35 soreau: DemiMarie: I probably sound like a broken record but FWIW, wayfire allows xwayland clients to position themselves
15:36 DemiMarie: soreau: Does Wayfire populate the workarea properties?
15:37 soreau: what do you mean?
15:37 DemiMarie: The X11 properties that indicate e.g. where the panel is, so one doesn't draw over it by accident.
15:38 soreau: I'm not sure exactly but ext-workspace was recently merged..
15:38 soreau: not sure if that helps anything
15:39 soreau: of course maximize works as expected at least, to avoid under/over panel areas
15:40 soreau: I think if a client tries to place itself at e.g. 0,0, wayfire clamps to workarea
15:41 DemiMarie: That's interesting.
15:42 DemiMarie: I had assumed that using Xwayland for this would be totally broken.
15:50 wlb: weston Merge request !1660 opened by () Draft: doc/scripts: Add scripts to print KMS page flips per second https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1660
16:19 drakulix[m]: <DemiMarie> "I wonder if the difference is..." <- Which is why I think you should take a far more active approach and do a proxy compositor in between your VMs and the host compositor. But that's just my two cents.
16:24 DemiMarie: <drakulix[m]> "Which is why I think you..." <- Would you be interested in going into more detail? The current plan is to have a filtering protocol-level proxy and then move subsurface compositing to the VMs, but I am curious what you would do differently.
16:25 DemiMarie: Also for clarification my issues regarding desktop environment stuff are about code running on the host or GUI VM. It uses protocols that guests won't have access to.
16:27 DemiMarie: drakulix: thanks for the suggestion.
16:28 drakulix[m]: Sure we can go into more detail, but I think I would need to understand your current issues better at first. I assume you plan to support a bunch of different environments in your GUI VM. So whatever you can come up with has to be a best efford based on protocol support of the host.
16:29 drakulix[m]: But e.g. for the panel, I would consider shipping your own, rather than proxy something on the level of ext-tray and have a fallback that uses StatusNotifierItems with obviously reduced feature set.
17:12 DemiMarie: drakulix: You assume correctly. The current plan is to support a subset of protocols that are supported by all of the supported compositors, plus maybe some more if a compositor happens to support them.
17:15 DemiMarie: For the panel, I don't want to have to change the UI (which works just fine under X11!) just because of Wayland limitations, at least if there are any alternatives. In this case, the obvious alternative is to use layer shell with carefully-specified margins or X11 override-redirect windows.
17:16 soreau: the panel surface usually isn't the issue, it's those pesky panel widgets that end up being problematic ;)
17:31 DemiMarie: soreau: that they do.
17:36 soreau: I ran xfce4-panel natively on wayfire about a year or so ago.. it worked pretty well but many of the widgets weren't ported (to wayland) yet so I couldn't build them
17:37 soreau: I think they're actually panel plugins though, not widgets