07:31 <wlb> weston Issue #1034 opened by Rishikeshan S/L (rishikeshan) VNC render to VNC-unauthenticated Unix sockets https://gitlab.freedesktop.org/wayland/weston/-/issues/1034

09:21 <wrl> hey, is there a way to get some sort of signal/notification of when the screen is locked via ext-session-lock-v1? i've been reading through the protocol docs, wlroots implementation, etc... not sure if there's something i'm missing but it doesn't seem like it

09:23 <vyivel> wrl: as the session lock client, it's the ext_session_lock_v1.locked event; otherwise, a third party can't detect this without compositor-specific mechanisms

09:26 <wrl> vyivel: got it, okay. my use-case is a bit pedestrian - i'm writing a cute little pomodoro clock and i would like it to pause while the screen is locked

09:27 <vyivel> for performance reasons?

09:27 <wrl> i did see that there's hyprland-lock-notify-v1 (which i suppose is what you're alluding to with "compositor-specific mechanisms"), but other than that i suppose there's nothing?

09:28 <vyivel> maybe there are non-wayland ipc ways for other compositors

09:28 <wrl> vyivel: well, again, kinda pedestrian but - i happened upon somebody's take on pomodoros in which they're sort of always running in the background

09:28 <wrl> and i decided it was compelling so i've implemented my own take on it

09:29 <vyivel> i mean

09:29 <wrl> but naturally it doesn't make a lot of sense to have a bunch of them just racking up in the background while the screen is locked

09:29 <vyivel> if it's just to avoid rendering, you should rely on the compositor to not fire frame callbacks when the clock isn't visible

09:30 <wrl> part of the concept is that they're always running but you can say "yes i am doing <thing> for this pomodoro", and it all gets logged, so at the end of the day you can look at it and say "i was actually doing things 30% of the time"

09:30 <wrl> it's just a way of sort of artifically introducing some time pressure

09:30 <wrl> vyivel: i mean the rendering is cheap as, that's not it

09:31 <wrl> it's entirely the functionality of being able to differentiate "25 minutes that went by because i was sat at the computer but just idly scrolling (or whatever)" and "25 minutes that went by but my screen was locked so it doesn't count"

09:32 <vyivel> you could detect idleness then maybe

09:32 <wrl> hm yeah that could work

09:32 <vyivel> or you can probably make some ipc thing to pause/resume it; this way, you could run it from the lock client, or from some keybinding or script or whatever

09:32 <wrl> ext-idle-notify-v1?

09:32 <vyivel> yea

09:33 <wrl> the ipc to pause/resume is honestly probably the least painful thing i could consider

09:34 <wrl> i'll look into idle notify though

17:27 <isf369> are there any 'staging' protocols that are being considered for 'stable' coming up?

17:34 <Consolatis> stable basically just means old and established, that is about the only difference in terms of quality or adoption compared to staging

17:34 <Consolatis> absolutely nothing wrong with using staging protocols

17:35 <Consolatis> the whole separation is kind of weird IMHO

17:37 <isf369> ok, thanks, so 'stable' is essentially just tried and true 'staging'

18:44 <SardemFF7> I always considered: experimental (was unstable?) = we may break it whenever until we’re satisfied, adopt if you want ; staging = please adopt, we need testing, we may still break it but we’ll try extra hard not to ; stable = we won’t break it any more

19:04 <zamundaaa[m]> SardemFF7: no protocol can ever be broken once merged

19:05 <zamundaaa[m]> Backwards incompatible changes are never on the table, only new major versions

19:05 <SardemFF7> which is the same as my saying break, but whatever

19:06 <SardemFF7> /yes/ the old version “still works” but hopefully nobody will use it any more so that just make it useless and “broken”

19:07 <Consolatis> no, it isn't the same. a new protocol will have a new xml file. so existing software supporting the old protocol keeps working and new client software may consider supporting both protocols or just the old one or just the new one depending on the availability of the two

19:08 <Consolatis> within each protocol there are also "versions" which can be selected during runtime up to the most recent version a compositor supports. that is completely different to basically a new protocol though

19:23 <emersion> i would prefer "deprecated" instead of "break" here :P

19:23 <emersion> ("break" has confused numerous people before)

19:24 <emersion> but yeah, everybody's on the same page, just a wording thing