02:00 <rai> Hi, I am writing my first Wayland client and I am running into frustration because I have to define a zillion empty callbacks for events that I never intend on using. My specific grievance is in wl_output events vs. zxdg_output_v1 events - I need some info from both, but there is a lot of duplication. I found this issue[0] which has explained why this is the case, so I ask instead: does anyone have recommendations for dealing with this easier?

02:01 <rai> [0]: https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/341#note_2118440

02:01 <rai> I have seen others write a simple "noop" callback that takes no arguments, but unfortunately my warning level is high enough that I cannot do this.

02:08 <raiguard> (I am rai, just switched to my bouncer)

02:16 <danieldg> you could use a higher level api that does all of this for you

02:16 <danieldg> or just handle the raw protocol

02:17 <raiguard> I was originally going to use SDL, but this app will use wlr-layer-shell and using that with SDL was a pain. I would rather not go even lower level because that would take even more time than just writing stub callbacks.

02:18 <raiguard> In any case, I have realized that I probably don't need anything from wl_output, so this specific case won't be as bad as it was looking.

02:18 <danieldg> you probably will want outputs, but perhaps you don't need xdg outputs

02:19 <raiguard> I need xdg outputs for the logical positioning

02:20 <danieldg> you could just use relative positions, you know

02:24 <raiguard> Relative positions?

02:26 <danieldg> I guess for layer shell it'd just be the edge(s) and output

02:26 <raiguard> Ah.

02:27 <raiguard> That won't work for my usecase. The app I'm making is a Wayland version of this: https://github.com/tsoding/boomer

02:27 <danieldg> so... grab a screenshot and then zoom it as normal on that output, fullscreened?

02:28 <danieldg> that seems like it could be done without layer shell at all, actually

02:28 <raiguard> I am using layer shell so that it can exist on top of fullscreen windows in Sway

02:29 <raiguard> I dpon'

02:29 <danieldg> fullscreen is on top of everything but overlay

02:29 <danieldg> which is usually what you want

02:29 <raiguard> Usually, but not always

02:30 <danieldg> zooming the active desktop instead of a snapshot needs compositor help, but is a much neater thing to do :)

02:30 <raiguard> That would be neat, yes :D

02:30 <raiguard> For now I am keeping the scope low - take a screenshot, display it on top of _everything_ (including fullscreen windows) and zoom in.

02:31 <raiguard> You're right that I don't really need to know the logical positioning of displays for that...

02:32 <danieldg> I've used wl-mirror for this, to zoom in on another output

02:32 <danieldg> or a pre-defined region

06:46 <psykose> raiguard: you might also like https://github.com/negrel/wooz as inspiration

08:50 <wlb> weston/main: Pekka Paalanen * gl-renderer: add offset to the color mapping matrix https://gitlab.freedesktop.org/wayland/weston/commit/b15dcfe79036 libweston/ color.h renderer-gl/fragment.glsl renderer-gl/gl-shaders.c

08:50 <wlb> weston/main: Pekka Paalanen * color-lcms: accept matrices with offset https://gitlab.freedesktop.org/wayland/weston/commit/5ca78cdf0595 libweston/color-lcms/color-transform.c

08:50 <wlb> weston Merge request !1745 merged \o/ (gl-renderer: add offset to the color mapping matrix https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1745)

10:03 <zzag> jadahl: two weeks have passed. should we merge https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/392 ? according to the current workflow policies, it's all good now

10:05 <jadahl> should I change the disclaimer to something else first?

10:09 <zzag> uh, I don't think so? if somebody introduces a new disclaimer, I imagine that MR will fix the one in the session management protocol

10:09 <jadahl> could take the one from https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/394/diffs?commit_id=06dc37765dcf9a88fa04d7c1ea5aff6924b8016b I guess

10:09 <swick[m]> can we please figure out how the experimental stuff is supposed to work before we merge something and then have to figure out how move things over?

10:09 <swick[m]> there really is no reason to rush this

10:10 <zzag> swick[m]: well, that's reason why we proposed experimental protocols in the first place... so protocols don't get stalled

10:10 <zzag> If we adapt new policies, other protocols can be adjusted

10:10 <kode54> lol

10:10 <kode54> someone I follow

10:10 <kode54> their project was recently broken

10:11 <kode54> because ext image capture now requires ext foreign toplevel and they weren't including that before

10:11 <kode54> how they have a compositor with windows and weren't including foreign toplevel already, I don't know

10:12 <kode54> oh, he's here

10:12 <kode54> vyivel: hi

10:13 <kode54> only reason I updated your thing today was I was inspired to test it again and see how it's progressed in the months since I last looked at it

10:13 <kode54> I'm also following labwc, wayfire, and cosmic-comp

10:13 <kode54> well, and mutter and kwin, but mostly don't like to use either of those

10:13 <vyivel> hm i think ext-image-capture-source had a dep on ext-foreign-toplevel-list since initial release

10:14 <kode54> oh, hmm

10:14 <jadahl> swick[m]: it's no big deal imo, no xml file is installed, implementations are likely to copy it around anyway, it's just for documentation purposes, and the experimental protocol xml will be removed once it goes into staging. ironing out regulations how exactly name things etc can happen independently

10:14 <kode54> oh, didn't know swick was back, guess I haven't been paying attention to things

10:15 <zzag> jadahl: and we need a place to store snapshots somewhere. experimental/ seems like a reasonable choice regardless what future policy we choose

10:15 <jadahl> right

10:19 <jadahl> zzag: none the less, the disclaimer is a bit misleading, it's the one from staging iirc

10:22 <zzag> Yeah.. The only thing that I don't like is waiting a whole other 2 weeks :(

10:23 <zzag> I think the disclaimer can be changed, but it doesn't _have_to block the rest

10:23 <jadahl> I don't think we need to wait anything after changing the disclaimer

10:24 <jadahl> the 2 weeks timer isn't bumped on each update, only when the mr was created, iirc

10:25 <swick[m]> I'd rather the MR follow the practices outlined in https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/394 because the way people usually work is that they copy whatever is already there

10:25 <swick[m]> so setting a bad example would be unfortunate

10:27 <zzag> swick[m]: well, you see, we have already processes in place.. and not following them here will also set a bad example because if you don't like something semi-related, you can complain about it and just drag on the conversation in the protocol MR

10:27 <jadahl> I'm not convinced we'll end up with `-devel` though, could just as well be `xx-blabla-vN`

10:27 <zzag> "and just drag on the conversation in the protocol MR" which is a source of so much pain in the wayland-protocols development process :(

10:28 <swick[m]> this is about the general process, not about protocol specifics... being the first has its downsides

10:29 <swick[m]> iow the problem here is that the MR doesn't actually properly follow the procedures that we have put in place

10:29 <jadahl> suffix nitpicks aside, what's the difference between !392 and !394?

10:30 <pq> Is there something I should chime in to?

10:33 <zzag> swick[m]: "iow the problem here is that the MR doesn't actually properly follow the procedures that we have put in place" erm, I don't think so.. currently, it's fine according to what we have in master (and that's all I'm trying to do.. to adhere to the things that we had agreed in the past because otherwise it means that the development workflow we agreed on doesn't work)

10:33 <zzag> "that the development workflow we agreed on doesn't work" and same can be then applied to future version of experimental protocol workflow as well

10:34 <zzag> because somebody just doesn't really like it

10:34 <jadahl> pq: the context is !392 and !394. !392 can according to governence land, but the exact details how is not entirely clear (what directory, suffix, ...). !394 tries to introduce an exact "work flow", which !392 may or may not exactly follow. what !394 will end up being is up to the future

10:36 <zzag> swick[m]: and I just want to stress again that the workflow model _can_ be changed; it's not carved in stone but let's implement the policies that we agreed on

10:36 <zzag> otherwise they are meaningless

11:09 <pq> jadahl, so far I've got the feeling that we must differentiate between experimental protocols merged upstream in experimental/ vs. not merged ones.

11:10 <pq> merged ones must bump major version on breaking changes, while non-merged branches do not need to.

11:14 <pq> I think getting !393 landed would clear up the terminology so we can actually talk about the issue.

11:22 <jadahl> Yea perhaps. I think it's only valuable to document and clarify what actually goes into the repo, not what people do on their own unmerged branches

11:24 <pq> I see value in *recommending* what people do with their unmerged public branches, but of course wayland-protocols cannot mandate anything.

11:27 <pq> To me protocols are similar to kernel DRM UAPI in the sense that there shouldn't be incompatible versions used in the wild under the exact same interface name.

11:28 <pq> Some general guidelines to maintain that would be useful.

11:29 <mclasen> that mostly comes down to "don't enable experimental protocols by default" ?

11:30 <pq> yeah

11:30 <pq> jadahl, GOVERNANCE sections are out of order, I thouht 2.3 didn't have a mention of experimental

11:32 <zamundaaa[m]> mclasen: no, it means that there shouldn't be two protocols with the same name + major version but different API/ABI

11:32 <zamundaaa[m]> Experimental or not doesn't matter

11:32 <pq> it's also confusing, when e.g. 2.2 says one thing, and then 2.2.1 overrides... all of 2.2?

11:33 <pq> zamundaaa[m], how do you define existence ("be") there?

11:34 <jadahl> pq: I think the point is that experimental protocols (i.e. protocols placed in experimental/ in the repo) are special case, where nothing from the normal formalities apply

11:35 <pq> jadahl, sure, but GOVERNANCE is confusing now.

11:35 <pq> the point is good, the delivery could be better

11:35 <jadahl> 2.2.1 should perhaps define the meaning of experimental to make it clearer?

11:35 <zamundaaa[m]> pq: it simply shouldn't be merged anywhere, neither in wayland-protocols nor implementations

11:36 <pq> jadahl, and 2.2(.0) needs to say it does not apply to experimental. 2.2.1 does not iterate every sentence in 2.2(.0) to reject them.

11:37 <pq> jadahl, see how I have a hard time referring to one section without including the other :-)

11:38 <pq> zamundaaa[m], ok. That could use some written guidelines.

11:40 <jadahl> then 2.2.0 must also define experimental, must it not?

11:40 <pq> sure, definition is a different problem

11:45 <jadahl> pq: you mean you want something like https://paste.centos.org/view/35082df9 ?

11:48 <pq> no, that's an exception as an "afterthought". I would more like add a new heading: ### 2.2.0 Non-experimental protocol inclusion requirements

11:48 <pq> one more #

11:48 <jadahl> ah, sure, or "Staging and stable protocol inclusion requirements"

11:49 <pq> yes

12:02 <any1> kode54, vyivel: image-source depending on foreign toplevels is a bit of a nuisance. I think that maybe it should be the other way around. Or maybe there should have been a toplevel-image-source protocol that only creates image-sources from toplevels.

12:05 <emersion> any1: image-source has different globals, one per source

12:08 <any1> emersion: I'm not sure I see what you're trying to tell me

12:08 <emersion> i don't think it

12:08 <emersion> 's an issue

12:09 <any1> There's no issue. I just think that it's conceptually awkward.

12:09 <vyivel> the only problem is that you hsve to generate code for foreign toplevels too

12:10 <vyivel> which is fine

12:11 <any1> but, yeah, I think that maybe there isn't really any perfect solution that's not awkward in any way.

12:29 <wlb> wayland-protocols Merge request !404 opened by Jonas Ådahl (jadahl) GOVERNANCE: Make it clear protocol requirements apply to staging/stable https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/404 [governance]

12:29 <jadahl> pq: ^^

12:30 <pq> aye

12:39 <raiguard> psykose: Drat, that's pretty close to exactly what I was going to make! Thanks for the link.

12:49 <raiguard> s/was/am

17:40 <wlb> weston Merge request !1750 opened by Derek Foreman (derekf) Draft: xwm: Fix crash when querying position of XWAYLAND windows https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1750 [XWayland]