06:19karenw: So, on my copy of wayland-protocols. Cursor Shape (staging) depends on tablet v2 (unstable). That seems... weird?
06:20karenw: I would assume that something in staging can't depend on unstable, and anything in stable can't depend on something in staging/unstable?
06:21whot: karenw: the tablet protocol has been declared stable in one of the last releases
06:23karenw: Why I said 'on my copy' it is the correct way round on wayland.app.
06:28karenw: Is Cursor Shape intended to eventually replace .set_cursor() for most applications? Or purely an optional extra? (My question is mainly for desktop compositors)
06:45colinmarc: karenw: games will probably always set custom cursors, I think
06:48karenw: The way the core protocol is structured it's impossible for a compositor not to support it. I was more thinking of applications that only use common/theme cursors.
06:48karenw: Regardless, for the foreseeable future I need to support both.
07:29jadahl: karenw: think of it more as an optimization, unless your client only intends to support a specific compositor version.
07:30jadahl: an opportunistic optimization, that is
08:03MrCooper: benh: you only need to worry about conflicts, a straightforward rebase can easily be done as part of merging
08:05vyivel: can i get another look at https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/394?
08:07MrCooper: benh: gitlab should send you an e-mail notification when your MR conflicts with main
08:08benh: okj
08:08benh: MrCooper: yeah it did yesterday (conflict with the CI file of course) so I rebased... I suppose now I just wait for somebody to pick it up ?
08:09MrCooper: probably, yeah
08:53Vanfanel: Hello. When building libwayland manually and installing it, there's no .cmake file generated/installed, so doing something like "find_package(Wayland)" fails.
08:53Vanfanel: Is there a way to get the .cmake file generated by the Meson build system for Wayland? Or is pkg_check_modules() the usual way to use CMake in projects linking against libwayland?
08:54davidre: pkg_check_modules or write your own FindWayland.Cmake or use https://invent.kde.org/frameworks/extra-cmake-modules/-/blob/master/find-modules/FindWayland.cmake
08:55vyivel: can't a .pc file be used?
08:56davidre: Using pc file from Cmake is done via pkg_check_modules so yes
08:58Vanfanel: Ah, ok, I will use pkg_check_modules then. I can't count on extra cmake modules being installed on other user's systems. Thanks!
09:00davidre: You could vendor that file as well, I think Qt does that
13:57wlb: weston Issue #939 opened by Sriharsha P V (Sriharsha) None of the options functioning in Firefox settings https://gitlab.freedesktop.org/wayland/weston/-/issues/939
14:38wlb: wayland-protocols Merge request !326 opened by Orko Garai (orko) text-input: Use cursor begin and end in set_surrounding_text https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/326
15:10wlb: wayland-protocols Merge request !327 opened by Orko Garai (orko) text-input: Clarify anchor in set_surrounding_text https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/327
15:15wlb: wayland-protocols Merge request !326 closed (text-input: Use cursor begin and end in set_surrounding_text)
15:49wlb: weston Issue #937 closed \o/ (Flickering & freezing seen in Firefox & Chrome application https://gitlab.freedesktop.org/wayland/weston/-/issues/937)
15:49wlb: weston/main: Derek Foreman * compositor: Destroy paint nodes in weston_view_move_to_layer() https://gitlab.freedesktop.org/wayland/weston/commit/5fe02dc68e08 libweston/compositor.c
15:49wlb: weston Merge request !1591 merged \o/ (compositor: Destroy paint nodes in weston_view_move_to_layer() https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1591)
22:54karenw: Are there any other compositors other than weston that can be run as a window inside another compositor?
22:54feaneron: mutter / gnome-shell has a nested mode
22:54feaneron: i think gala, as a user of mutter, does too
22:56ifreund: wlroots has a wayland backend, so pretty much all wlroots compositors too
22:57ifreund: its a very useful feature for compositor development, so pretty much every compositor supports it
22:57Company: I learned recently that someone wrote a compositor running as a GTK widget
22:58Company: but I think that's based on wlroots
22:58feaneron: the UI preview of Cambalache (gtk4 ui editor) is a nested compositor based on wlroots
22:58karenw: Yeah, it's a useful feature for application devs too, I can test on different compositors without relogging
22:59Company: (as long as you don't test features which nesting doesn't support)
23:03karenw: TIL my code doesn't run on sway. `xdg_surface@11: error 3: xdg_surface has never been configured`
23:03karenw: I tried injecting a display_roundtrip after creating the window before first attaching a buffer/commiting but I still don't get a configure?
23:09zamundaaa[m]: karenw: you need to actually wait with the first buffer until you get the configure, not just do a roundtrip
23:13karenw: zamundaaa[m]: So... that could be indefiite? My code currently assumes once I've made the wl_surface and xdg_toplevel that I can just hand everything over to vulkan.
23:18zamundaaa[m]: karenw: if the compositor *never* sends the configure event, that would be a bug
23:19zamundaaa[m]: In general though, unless the protocol text for an event has specific guarantees about when it'll be sent, you can't make assumptions about it
23:21karenw: Yeah I never seem to get a configure if I just sit in a poll event loop forever. I'm missing something but I don't know what.
23:24karenw: (I disconnected there if anyone replied to me)
23:25karenw: Ah, I need to do a wl_commit before attaching the first buffer
23:25karenw: *wl_surface_commit