feat(wayland): add a lib for central wayland connection management #371
Conversation
|
This is still creating a separate wayland connection to GDK's, right? That's certainly easier to manage, but I don't think it could be used to implement protocols like hyprland-focus-grab which use wl_surface objects (that live in GDK's wayland connection), could it? |
|
The intent is to stay independent from the gdk version, otherwise each lib would need separate versions for gdk3 and gdk4, which i want to avoid, as this is unnecessary for most libs, like eg river, idle notifications, foreign toplevel and more. When you need the wl_surface from a window, you need to use gdk/gtk api anyway, in which case you can just use the wl_display provided by gdk. |
|
Alright then, makes sense. I don't think there are any wayland protocols that would both be cool to include in Astal and that would require surface access other than hyprland-focus-grab anyway, so there really isn't much of a point in fussing around with GDK versions anyway. For the hyprland-focus-grab binding which I do want to make... eventually... I don't think there's a good way to do that with both a high-level interface and supporting both GTK versions. But that's not the focus of this PR anyway. |
when either gdk3 or gdk4 is loaded, use its wl_display, create own connection otherwise
not anymore. If gdk is loaded before AstalWl.get_default() is invoked, it will use that ffor the wl_display and only uses its own connection as a fallback. |
|
the astal-wl lib exposes properties for wl_display and wl_registry, which vala put in the gir as Wl.Display and Wl.Registry as types. This causes issues, as eg the type generator for ags tries to resolve the Wl namespace, which does not exist outside of vala. So for now i just don't generate the gir and typelib, as this lib is intended for use in other astal libs, which will work fine, as the generated vapi and c header is correct. |
adds wl-vapi-gen as a dependency
meson will generate sources using wl-vapi-gen at build time. generators are only evaluated during a build, but the lsp wont build the project, it only intropects the build targets and builds the dependencies, so the lsp will generate the vapi files when using custom_targets instead of generators.
the River lib will be ported in its own PR
from the main branch, as it is needed by the river lib, will be removed in the AstalRiver rewrite PR
With a look into the future, we will implement more wayland protocols, so instead of each lib creating its own connection to the wayland compositor, this PR adds lib which manages the wayland connection and its global objects in a central place, so the same connection can be used by several libs. I already updated the river lib (the only lib implementing a wayland protocol 1) and seems to work fine.
TODOS:
Edit:
I wrote a wl-vapi-gen a while ago, which generates a vapi file for a a wayland protocol, so the c stub generated by wayland-scanner can be used in vala. This tool can come in handy soon.
Footnotes
just for completeness, this isn't actually true, the Astal3 lib does implement the idle-inhibit protocol, but that uses gdks wayland connection, and therefore not relevant here. ↩