00:19 i509vcb: Is there some intended way to limit the number of objects a client could create?
00:28 danieldg: I would assume that a simple count would be one part of a resource-counting system that would eventually result in a fatal error on exhaustion (because there's no protocol for nicely informing the client of this, to my knowledge). That feels very compositor-specific.
00:29 i509vcb: Well if the client creates too many objects I could always just kill it
00:29 danieldg: right
00:29 danieldg: I don't think you have any other choices
02:10 wlb: weston Issue #892 opened by Zhongmin Wu (vwzm228) Find some issues about VNC backend + gl renderer, hope helpful for weston maintainers to fix them https://gitlab.freedesktop.org/wayland/weston/-/issues/892
09:38 wlb: wayland-protocols/main: Simon Ser * tablet-v2: clarify that name/id events are optional https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/0819d97313b3 unstable/tablet/tablet-unstable-v2.xml
09:38 wlb: wayland-protocols Issue #180 closed \o/ (tablet-v2: clarify whether zwp_tablet_v2.id is required https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/180)
09:38 wlb: wayland-protocols Merge request !286 merged \o/ (tablet-v2: clarify that name/id events are optional https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/286)
12:49 wlb: wayland-protocols/main: Carlos Garnacho * staging/dialog: Add "dialog" protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/9408483fb19e staging/xdg-dialog/README staging/xdg-dialog/xdg-dialog-v1.xml meson.build
12:49 wlb: wayland-protocols Merge request !228 merged \o/ (staging/dialog: Add "dialog" protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/228)
13:22 wlb: weston Merge request !1478 opened by Pekka Paalanen (pq) color-lcms: print profile id instead of pointer https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1478 [color-lcms plugin], [Colour management]
15:45 haasn: is there a wayland clipboard manager that supports images / non-text?
15:45 haasn: by "clipboard manager" I mean something that will keep my clipboards synchronized
15:45 haasn: I currently use `wl-paste -pw wl-copy` but it has two issues: 1. supports text only, and 2. only synchronizes in one direction, I want both
15:46 kennylevinsen: haasn: for the first part, `man 1 wl-clipboard`, look for --type.
15:48 pq: cli tools to access the clipboard are kind of not supposed to work to begin with...
15:51 haasn: kennylevinsen: that only works if I want to force a specific type, no? but I want to sometimes copy text and at other times copy images
15:52 psykose: the issue is that when you copy 'an image' in firefox, it might advertise a lot of types
15:53 kennylevinsen: haasn: you're not forcing a type, you're specifying which of the numerous offered types to pick
15:53 psykose: so you would copy a bunch of the same image in different formats if it just pulled them all
15:54 kennylevinsen: there are dedicated clipboard management tools (wlroots at least has a protocol for that), but I'm not personally familiar with them.
15:55 haasn: well, it seems that `wl-paste -t image -pw wl-copy` doesn't break when copying text
15:55 haasn: so I guess I can use that to work around the most common case of this issue
15:55 haasn: although it will probably still break on files and the like
15:57 emersion: pq, (1) there are OSC extensions for clipboard access (2) this is a clipboard manager use-case
15:58 pq: OSC? like a terminal emulator? then you have a window, so that's fine.
15:58 emersion: CLI tools can access the clipboard via escape sequences
15:58 emersion: the terminal emulator then relays this to Wayland/X11
15:59 pq: but you need a terminal window to actually relay those, right?
15:59 emersion: sure
15:59 haasn: fwiw I am copying from one GUI app to another GUI app
15:59 emersion: it's good for CLI text editors for instance
15:59 pq: so, there is a window associated to it, which makes it fine
15:59 emersion: but for background CLI tools, it's a clipboard manager use-case, so it's only natural that it uses something else (privileged protocol)
16:00 pq: privileged protocol is fine, I didn't realise they used that
16:00 emersion: wl-clipboard does that, yeah
16:00 emersion: it only uses hacks on GNOME
16:00 pq: wl-paste and wl-copy though?
16:00 emersion: part of wl-clipboard
16:01 pq: oh, ok
16:01 davidre: plasma also uses wlr-data-control
16:01 davidre: and supports images just fine which was the originial quesiton
16:01 davidre: s/quesiton/question/
16:02 emersion: s/GNOME/GNOME and Weston/, i suppose
16:03 pq: yeah, Weston has... not really a solution for authenticating clients
16:08 haasn: wait, primary selection and the regular clipboard are implemented with completely different protocols?
16:11 haasn: yeah seems it's via wl_data_device and zwp_primary_selection_device_v1
16:12 haasn: and then there's also wlr-data-control..
16:12 haasn: and gkt-primary-selection ?
16:12 haasn: why so many different clipboard protocols?
16:12 davidre: wlr-data-control is for clipboard manager s
16:12 haasn: and how can I get rid of them all and have just a single clipboard?
16:13 davidre: gtk- is non standard and was standardized into primary-selection (please correct me if I am wrong)
16:13 davidre: wl_data_device handles the clipboard
16:14 davidre: and primary_selection the primary_selection
16:14 haasn: darn
16:14 davidre: the thing you get when selecting text and pasting by middle click usually
16:14 haasn: that really stymies my plan, I was hoping it would be a simple hack patch to redirect the primary selection to the clipboard (or vice versa)
16:14 haasn: but if they're completely different protocols internally that plan is gone
16:15 davidre: If you are the clipboard manager you can do that
16:15 davidre: * do that with wlr-data-control quite staightfoward
16:15 davidre: And if you want to synchronize both for your app, set them to be the same it's also not that hard
16:16 davidre: depending on which level you are operating, toolkit, wrapper, raw generated code
16:17 haasn: I am the end user who is suffering from this design, coming from X where things just worked (tm)
16:18 emersion: it's unfortunate that primary-selection needs to be a completely separate protocol
16:18 emersion: it would've been nicer to update the core protocol to be more modular
16:30 davidre: on plasma you can just enable synchronize clipboard and primary selection :)
16:30 haasn: good for plasma users :/
16:31 haasn: maybe the plasma clipboard manager can be ripped out and ran stand-alone
16:31 haasn: but probably not as I imagine it is part of the compositor itself
16:31 davidre: It is not
16:32 davidre: it uses wlr-data-control but it's part of the shell somehwat and cannot run standalone
16:36 emersion: it would indeed be nice to have a good standalone clipboard manager
16:37 emersion: i've seen too many that just hack together CLI tools
16:37 psykose: personally i disabled primary so that is synced enough :P
16:47 haasn: people seem to be recommending copyq
16:48 haasn: I'll give it a spin
20:35 nmeum: hi! I am a bit confused regarding the distinction between xdg-output-unstable-v1, wlr-output-management-unstable-v1 and wl_output. I would just like to be notified when a new output/monitor is hotplugged, what do I best use for this purpose?
20:40 vyivel: nmeum: checking for new wl_output globals would probably be the best option
20:42 nmeum: so everytime a new monitor is hotplugged a global event on the wl_registery is emitted for the wl_output interface?
20:42 vyivel: yep
20:44 nmeum: hm, somehow I only see a global event for the monitors on startup but maybe that's just a bug in my code
22:16 danieldg: nmeum: you can run with WAYLAND_DEBUG=1 to see when you get the events