<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 31, 2016 at 2:29 PM, Sebastian Kügler <span dir="ltr"><<a href="mailto:sebas@kde.org" target="_blank">sebas@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Discussed with mgraesslin on IRC, preliminary conclusion below...<br>
<span class=""><br>
On dinsdag 31 mei 2016 14:05:06 CEST Sebastian Kügler wrote:<br>
> <a href="https://bugs.kde.org/show_bug.cgi?id=358011" rel="noreferrer" target="_blank">https://bugs.kde.org/show_bug.cgi?id=358011</a> dual screen not setup after<br>
> reboot<br>
><br>
> This bugreport seems to be a common problem, and it's a good example for<br>
> what's wrong with the screen configuration on startup.<br>
><br>
> TL;DR: We have a race condition when the kscreen daemon starts. It looks up<br>
> a  known config, then applies it and subsequently resaves the config. The<br>
> same happens on config changes, it writes, then re-reads and then re-writes<br>
> the config change.<br>
> I've managed to prevent this from happening by adding a timer that avoids<br>
> saving the config as a direct reaction to our own config changes.<br>
<br>
</span>So what we want to try is the same mechanism that KWin uses. Kwin watches for<br>
configuration changes for 100ms, if any change takes longer than 100ms, it's<br>
considered unrelated. Basically, what we want to do in kscreen daemon is:<br>
<br>
- start a timer in kscreen daemon for 100ms after SetConfigOperation::finished<br>
  and<br>
- restart it for every configChanged that arrives while the timer is still<br>
  running,<br>
- if the timer has timed out in the meantime, react to configChanged as usual<br>
<br>
That should achieve the same effect as the "current" timer approach (which was<br>
just a proof of concept to prove my point, anyway.<br>
<br>
Let's see how this goes.<br><br></blockquote><div><br></div><div>Perhaps blockSignals can help you out [1]?</div><div><br></div><div>object->blockSignals(true);</div><div>// ...</div><div>Write your changes</div><div>// ...</div><div><div>object->blockSignals(false);</div></div><div><br></div><div>Object should be the object that currently receives the notification that the config file has been changed i think.</div><div><br></div><div>[1] <a href="http://doc.qt.io/qt-5/qobject.html#blockSignals">http://doc.qt.io/qt-5/qobject.html#blockSignals</a> </div></div><br></div></div>