<div dir="ltr"><div dir="ltr">> <span class="gmail-im"></span> Well, at least slock (which is hard coded in current xflock4) and i3lock do not handle DPMS by themselves. Anyway, alternatively there could be a separate wrapper script for the job and user could set LockCommand to run it, so it would be independent of xflock4. I agree it would be less confusing that way besides being more modular.<span class="gmail-im"><br></span></div><div dir="ltr"><span class="gmail-im"><br></span></div><div><span class="gmail-im">Yup, that would be the "small start" I could imagine.</span></div><div><span class="gmail-im"><br></span></div><div><span class="gmail-im">> It’s only my opinion and I don’t speak for the Xfce team.</span></div><div><span class="gmail-im"><br></span></div><div><span class="gmail-im">Also: what Cyrille said, I couldn't agree more.<br></span></div><div><span class="gmail-im">It's true that the current situation is hard to completely understand for someone who doesn't know all the pieces (and you can expect that of pretty much any Xfce developer who is around now) and a diagram could help.</span></div><div><span class="gmail-im">Also tests (even if in the form of manually triggered shell scripts or manual test instructions) would help.</span></div><div><span class="gmail-im"><br></span></div><div><span class="gmail-im">Cheers</span></div><div><span class="gmail-im">Simon<br></span></div><div><span class="gmail-im"><br></span></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 4, 2021 at 12:22 AM Cyrille Pontvieux <<a href="mailto:cyrille@enialis.net">cyrille@enialis.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
First, I do not belong to the Xfce team.<br>
<br>
If you, Jarno, plan to make deep modifications in this area (locking, <br>
sleeping, DPMS, …), maybe a diagram of current situation and proposed <br>
situation could help (to agree or not, to alter the design, …)<br>
<br>
It will also be less scary with some sort of tests (I do not know if <br>
those components already have some or not). Tests for current situation <br>
first, then with the proposed evolution.<br>
<br>
Xfce dev team is a small team, and I’m not sure there is a person <br>
responsible for such big changes (in features) across different <br>
components/scripts.<br>
<br>
So, in my opinion, to convince, you should not only communicate (through <br>
email or such) but also prove (by automatic tests, reproducible builds, <br>
that kind of things) that your ideas are better than the status quo. As <br>
the team is small, any change needs to be fully apprehended by the <br>
maintainer and the result code should be as small and as simple as <br>
possible, even if not all cases are covered.<br>
<br>
This is just my advice after reading the discussion on this subject. <br>
It’s only my opinion and I don’t speak for the Xfce team.<br>
<br>
Cyrille Pontvieux<br>
_______________________________________________<br>
Xfce4-dev mailing list<br>
<a href="mailto:Xfce4-dev@xfce.org" target="_blank">Xfce4-dev@xfce.org</a><br>
<a href="https://mail.xfce.org/mailman/listinfo/xfce4-dev" rel="noreferrer" target="_blank">https://mail.xfce.org/mailman/listinfo/xfce4-dev</a></blockquote></div></div>