<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 8, 2015 at 9:14 AM, David Faure <span dir="ltr"><<a href="mailto:faure@kde.org" target="_blank">faure@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Sunday 04 January 2015 21:37:21 Mark Gaiser wrote:<br>
> Hi,<br>
><br>
> I was reading back an mailing list thread i started about half a year ago<br>
> [1]. Later on in that thread Aaron suggested a cool idea of "slave side"<br>
> sorting [2].<br>
><br>
> At that time i found it cool, but didn't really see a need for it. Dolphin<br>
> is doing a fine job at sorting anyway, so why would we bother moving it to<br>
> the KIO side. Well, a good reason for moving it to the KIO side just became<br>
> apparent to me when looking at this RR [3]. Sorting is already quite<br>
> complex in Dolphin. Adding in QCollator while also using threads makes it a<br>
> bit more nasty since a QCollator object per thread is required (hence the<br>
> RR).<br>
><br>
> Sure, the end result (and Dolphin is probably going to move there) is to<br>
> use QCollatorSortKey which will make sorting quite a bit faster [4] and<br>
> remove a QCollator requirement, but it won't be any cleaner. Quite the<br>
> opposite, It will be more complicated due to the bookkeeping required to<br>
> use QCollatorSortKey.<br>
<br>
</span>Moving complexity elsewhere doesn't make things less complex overall, though<br>
:-)<br></blockquote><div><br></div><div>True :(</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><br>
> All this sorting stuff is quite complicated and only available in Dolphin.<br>
> Other people would need to duplicate it's efforts for the same results.<br>
> That and considering that KIO is a framework that can be used by external<br>
> (non KDE) parties made me think that having slave side sorting might be a<br>
> very good thing to have. It would allow for performance optimizations that<br>
> everyone can use and allows every KIO user to easily add sorting. It would<br>
> completely remove a need for Dolphin to have sorting and would greatly<br>
> simplify code that uses KIO.<br>
<br>
</span>This is an argument for doing sorting in KIO. Sure, why not.<br>
<br>
But I don't see how it could be done slave-side. When using<br>
KDirModel/KDirLister the result of the directory listing is put into<br>
KDirListerCache and then reused from any view that wants to list that dir.<br>
These views might have different sorting... What then?<br></blockquote><div><br></div><div>Regarding KDirListerCache, i think that should stay as it is. The sorting should not influence the cache in anyway, the cache should just be a raw container of the actual data like it is now.<br></div><div>When you want to have a certain sorted view you simply get the cache back for that folder with a proxy on top of it that re-arranges the indexes in the sorted order.</div><div><br></div><div>You can compare this with any Q*Model class with a QSortFilterProxyModel on top of that. The principle is the same, the implementation would just be without models and directly on QVector/QList objects.</div><div>The extra memory overhead for sorting would just be one vector of ints. Fairly cheap :)</div><div><br></div><div>The issue i see here is different processes. KIO::listDir is a process, KDirListerCache lives in the client process. You want to do sorting in both processes.</div><div>1. When the client initially asks a listing you want to do the sorting as quick as possible to send back as little data as possible. So sorting on the SlaveBase side. As long as not all data is known in the KDirListerCache sorting would have to be done on the SlaveBase side. That would be the case to change sort order _while_ data is dripping in.</div><div>2. When all data is fetched you don't want to go over a socket to request a different sorting method so then you would need to have the same sorting operations on the KIO client side with data fed from KDirListerCache.</div><div><br></div><div>I do think that KIO would need a new class for this that can handle a set of predefined sorting and filtering operations if this entire "slave side sorting" is to be considered for KIO.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Sorting in the slaves is mixing "core" and "gui" issues, IMHO. It's not the<br>
slave's job to know what kind of sorting the view wants.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
In fact I see no advantage in implementing sorting on the slave side compared<br>
to sorting on the app side. If it's about not doing that in the app's main<br>
thread so it remains responsive, then threads are the alternative as you<br>
already noted.<br></blockquote><div><br></div><div>Just to be clear, when i said "slave side sorting" i meant sorting in - for instance - SlaveBase. Not in the actual slave plugins.</div><div>Where exactly, i don't know, but certainly before data is being send back to the application that requested a KIO::listDir.</div><div>Sorry if i confused you here.</div><div><br></div><div>The advantage i see with doing this is allowing data to be visible for the user as soon as data is available which will give the user a smoother and faster experience. It allows for a mechanism of "show me the first 100 items of this massive folder in this particular sort order". Something that isn't fully possible right now since the client would have to wait till all data has arrived over the socket, then sort it, then present it. All data would still have to be fetched on the slave side, but only X number of entries would have to be send to the client allowing it to immediately present the data. The rest of the data can then be fetched on a "need to know" basis. Eg. when scrolling down for the next batch of 100 items. By that time the slave would probably (depending on the folder size and sort order) be done fetching all items and is ready to immediately send those pre sorted batches to the client.</div><div><br></div><div>An added advantage is that the client could then just use KIO as streaming API. Just like a youtube api or whatever streaming api. The client would just have to implement "canFetchMode" and "fetchMode" if the Qt classes are used. It should prevent the client from needing to implement complicated threading and UI tricks to keep the UI smooth.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I haven't looked into QCollator in details, but isn't there a way to make it<br>
threadsafe?<br></blockquote><div><br></div><div>Don't know. Perhaps Aleix knows, but that's for another thread anyway :)</div><div>Or perhaps a Qt bug report.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
--<br>
David Faure, <a href="mailto:faure@kde.org">faure@kde.org</a>, <a href="http://www.davidfaure.fr" target="_blank">http://www.davidfaure.fr</a><br>
Working on KDE Frameworks 5<br>
<br></font></span></blockquote><div><br></div><div>CC'ing the people who initially sparked this idea. </div></div><br></div></div>