<html>
 <body>
  <div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
   <table bgcolor="#f9f3c9" width="100%" cellpadding="12" style="border: 1px #c9c399 solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
    <tr>
     <td>
      This is an automatically generated e-mail. To reply, visit:
      <a href="https://git.reviewboard.kde.org/r/122392/">https://git.reviewboard.kde.org/r/122392/</a>
     </td>
    </tr>
   </table>
   <br />





<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
 <p style="margin-top: 0;">On February 3rd, 2015, 7:23 a.m. UTC, <b>Martin Gräßlin</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">could you please split the review in a per-commit review? I find it hard to review as there are so many changes to different areas. Especially I think there are a few no-brainer which could go in quickly, while the threaded filtering is the part which needs most thought, so having that in a dedicated review would certainly help :-)</p></pre>
 </blockquote>




 <p>On February 3rd, 2015, 7:28 a.m. UTC, <b>Filip Wieladek</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Yes, I can do that once I get home. If you really believe that the popup is going away anyway, then I would however prefer to work on the new way, so that the "legacy" way can be removed.</p></pre>
 </blockquote>





 <p>On February 3rd, 2015, 7:34 a.m. UTC, <b>Martin Gräßlin</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">we probably cannot completely remove the legacy way as we still want to support the dedicated klipper mode without plasmoid. So improvements on that are still fine.</p></pre>
 </blockquote>








</blockquote>

<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I looked at splitting the change, but what hit me is that none of the changes I have make much of a difference unless I have background filtering. Unless background filtering is enabled, the UI still remains to be very sluggish. I have attached a screencast with the current version vs the version with my changes.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Note, that the UI is sluggish when there are a lot of entries (e.g. 2048) which are also long. This happens quite frequently in my workflow where I copy the contents of whole files</p></pre>
<br />










<p>- Filip</p>


<br />
<p>On February 8th, 2015, 5:08 p.m. UTC, Filip Wieladek wrote:</p>









<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="12" style="border: 1px #888a85 solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;">
 <tr>
  <td>

<div>Review request for Plasma.</div>
<div>By Filip Wieladek.</div>


<p style="color: grey;"><i>Updated Feb. 8, 2015, 5:08 p.m.</i></p>









<div style="margin-top: 1.5em;">
 <b style="color: #575012; font-size: 10pt;">Repository: </b>
plasma-workspace
</div>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
 <table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">This patch fixes multiple klipper issues:</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">* Moves filtering logic into a background task. This makes Klipper responsive while the clipboard is being filtered.
  Previously, Klipper would "hang" while it was filtering the results. This was worse when there were no matches as
  Klipper had to go through the entire history. THe computation is immediate on small history sets, but significant
  on larger sets with larger strings in the clipboard
* Provides a progress bar at the top to indicate the filtering process.
* Simplifies the code significantly, by:
   * Moving filtering in a separate class file
   * Cleaning up Popup proxy to build the menu directly using a QList
   * Removing the "index" magic in KlipperPopup. Now we maintain a list of history actions which can be easily cleared.
   * Removed explicit deletion of the "more" submenus, as these are owned by the parent menus and should be removed
&nbsp;    automatically
* Avoids flickering of Klipper while removing and inserting actions by forcing the height and width during the update.
* Fixes a potential memory leak. The QActions for the KlipperPopup were only removed, but never deleted. The API used
  to add actions addAction(QAction*) was not taking ownership of the action. This is fixed by deleting the actions
  manually when clearing.
* Fixes a performance issue during menu rendering when truncating large strings. The method call elidedText() can be
  slow on large pieces of text. This is worked around by creating a much smaller string of the prefix and suffix of the
  string. We use the average character width to compute the approximate amount of characters which can be displayed
  and use twice as much. (this is because in corner cases, such as |||| we might end up with a string which is not
  long enough).</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">This also fixes the bug https://bugs.kde.org/show_bug.cgi?id=238084</p></pre>
  </td>
 </tr>
</table>



<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">

 <li>klipper/popupproxy.h <span style="color: grey">(f33f62c117a08ddbe6b761da4c2e28e51b985044)</span></li>

 <li>klipper/popupproxy.cpp <span style="color: grey">(12dd3dd637d0ff9d134fb71237d6f0d3bcc5bd77)</span></li>

 <li>klipper/CMakeLists.txt <span style="color: grey">(a08f062480b15f32f049e2d0d0e311dbe2964c02)</span></li>

 <li>klipper/filterresult.h <span style="color: grey">(PRE-CREATION)</span></li>

 <li>klipper/filterresult.cpp <span style="color: grey">(PRE-CREATION)</span></li>

 <li>klipper/history.h <span style="color: grey">(1bfd0424714ff79d93206a74cb7e4214a6c8c652)</span></li>

 <li>klipper/history.cpp <span style="color: grey">(9640c23b0cf06dd0135ca573aea0819e2788b852)</span></li>

 <li>klipper/historyfilter.h <span style="color: grey">(PRE-CREATION)</span></li>

 <li>klipper/historyfilter.cpp <span style="color: grey">(PRE-CREATION)</span></li>

 <li>klipper/klipperpopup.h <span style="color: grey">(6f7b30747562b5e7227504b8c53be2863686072b)</span></li>

 <li>klipper/klipperpopup.cpp <span style="color: grey">(0b2f11d6d6d95e96ece0ac7b386fae2492ad0efd)</span></li>

</ul>

<p><a href="https://git.reviewboard.kde.org/r/122392/diff/" style="margin-left: 3em;">View Diff</a></p>



<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">File Attachments </h1>


 <li><a href="https://git.reviewboard.kde.org/media/uploaded/files/2015/02/08/1d998fd9-57fd-4997-92f8-11b8e038e795__screencast.mp4">A screencast with foreground processing vs background processing</a></li>

</ul>




  </td>
 </tr>
</table>








  </div>
 </body>
</html>