Porting dolphin to Qt5/KF5?

[Frank Reininghaus]

Hi Mark,

thanks for your message.

2013/9/18 Mark:
> Is there any schedule to start porting dolphin to Qt5(.2)? Specially since
> QCollator is in Qt now, it seems like a very nice time to start playing with
> Dolphin under Qt5. Testing it, benchmarking the sorting stuff, etc etc..
>
> I'm not planning on taking this - likely not so trival - port upon me since
> i'm still playing with UDSEntry optimizing stuff and other KIO parts.
>
> Is there anyone working on this?

I guess there is no real plan for the Qt5/KF5 transition yet, but I
agree that it would be nice to have a Dolphin version that can run on
Qt5/KF5 soon. There haven't been any real discussions about this
subject yet. I will post a random collection of my thoughts on the
issue here - if anyone has other thoughts, please speak up!

I think that we should continue to develop master based on Qt4 as long
as there are new KDE SC 4.x releases (probably shortly before the
first KF5-based release of "KDE Applications"?). We can still deliver
some improvements based on Qt 4 (like the cool stuff that Emmanuel is
working on, sorry that I could not look at that in detail yet), and I
think it would be a shame if that needed to wait a year or more for
its release. Moreover, I hope that unlike KWin and Plasma, which need
huge architectural changes for their transitions, Dolphin is
straightforward to port.

One could argue that making use of QML/QtQuick2 would be a good
mid-to-long-term goal, and I fully agree with that, but I think that
this will either require a *huge* amount of work or a major feature
loss at the moment (the last time I checked, there were still no tree
views available, but maybe that changed in the mean time? Also
grouping is not available in Qt's native item views AFAIK). And even
if everything that Dolphin currently offers was available in QML
out-of-the box, then we would still have to replace the current model
with a QAbstractItemModel-based one (something like KDirModel+the
additional features, like Nepomuk roles, that have been added in the
mean time) or find a good way to make the current code work nicely
with QML/QtQtuick2. Either way, I think it would be a huge effort,
definitely not something that I could do in the near future
considering that I do it all in my spare time ;-)

Therefore, I think that except for QCollator, there are currently no
major new features in Qt5 that we could make use of easily, and this
is why I think that we can continue to keep our main focus on the Qt
4-based version for a little while longer.

Still, having a working Qt 5-based version that people can play around
with would be cool. I would suggest that we follow Konsole's example
[1] and set up a "frameworks" branch at some point that contains just
the stuff that is needed to make it build with KDE frameworks, and
keep that branch as close to master as possible. Everything that could
be done in the Qt 4-based master to make the transition to Qt 5 easier
should be done there.

This will require some coordination with the other apps that we share
the repository with, however.

But now I've talked enough about my ideas already - what do other people think?

BTW, now that the QCollator/sorting issue is such a hot topic: I've
been meaning to write a message with some recent sorting-related ideas
of mine, but I did not really get round to it yet. Here is a short
version:

I think that we can drastically improve the "natural sorting"
performance even in the Qt 4-based version. The idea is quite simple
actually: First do a "non natural" sort, and then sort the array
"naturally". I tried that some time ago, and it did reduce the total
time required for sorting quite considerably. It works because our
"merge sort" implementation is able to make use of (partially) sorted
data, and reduce the number of expensive "natural" comparisons.

The gain would obviously be much larger with Timsort, that Emmanuel
has been working on. The only extra thing that would be nice to have
would be a Timsort that can make use of multiple CPU cores (to prevent
that the performance regresses from the current version for people who
do have many CPU cores, at least in the worst case where the "make use
of already sorted data" idea goes wrong). I do have some ideas about
that, but I don't have the time to write about it in detail now, and
it's off-topic for this thread anyway ;-)

Best regards,
Frank

[1]
http://quickgit.kde.org/?p=konsole.git&a=shortlog&h=b820dbf715b9c07f3dedea7bbc018d7a92647505
http://quickgit.kde.org/?p=konsole.git&a=commit&h=a83db71590a9faa85d2daee330c1f9d2ff958bb2
https://git.reviewboard.kde.org/r/111937/