<table><tr><td style="">hein added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D14542">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
          color: #6B748C;
          font-style: italic;
          margin: 4px 0 12px 0;
          padding: 8px 12px;
          background-color: #F8F9FC;">
<div style="font-style: normal;
          padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D14542#338981" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">D14542#338981</a>, <a href="https://phabricator.kde.org/p/davidedmundson/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@davidedmundson</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>QML and the rest is all fine.</p>

<p>I don't understand why desktopmodel is the way it is.</p>

<p>There are 2 DBus patterns one could do here.</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">we buffer all changes in a model locally, when the user clicks save we apply them on the server and recall initialise.</li>
<li class="remarkup-list-item">we do things async-realtime. The model is always in sync with remote changes. When the user clicks create/remove we send a request to the server; the model only updates when it gets the callback.
<br /><br />
This seems to be doing both patterns at once.</li>
</ul></div>
</blockquote>

<p>I don't understand this review comment, either. But I can try to explain what DesktopsModel does again in addition to the earlier comments in the hopes it clears things up:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">It initially gets the state from KWin and populates.</li>
<li class="remarkup-list-item">As long as the user makes no changes, KWin-side changes are directly exposed in the model.</li>
<li class="remarkup-list-item">If the user makes changes, it stops exposing KWin-side changes live, but it keeps track of the KWin-side change, so it can figure out and apply the delta on Apply.</li>
<li class="remarkup-list-item">When KWin-side changes happen while the model is user-modified, the user is informed that this has happened and that Apply will overwrite them.</li>
<li class="remarkup-list-item">After Apply, it syncs live again, until the user makes further changes, etc.</li>
</ul>

<p>From your comment, your second bullet was what the model used to do in the initial revision, when it was instant-apply. It's now delayed-apply. Your first bullet would work, but is clumsy and what this model does is better. It's not necessary to re-initialize and reset the model, because it's smart enough to figure out and apply the delta to the server, so at the end of that sync it ... well, knows it's in sync.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R108 KWin</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D14542">https://phabricator.kde.org/D14542</a></div></div><br /><div><strong>To: </strong>hein, mart, davidedmundson, ltoscano<br /><strong>Cc: </strong>zzag, davidedmundson, broulik, plasma-devel, kwin, mkulinski, ragreen, jackyalcine, Pitel, iodelay, bwowk, ZrenBot, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, mart<br /></div>