Porting dolphin to Qt5/KF5?

[Frank Reininghaus]

Hi,

2013/9/18 Mark:
[...]
> One question there, is dolphin going to remain in kde-baseapps or is it
> going to be in it's own repository? I think that is a very valid question
> with KF5 in mind where everything is split/moved around.

I'm not sure if anyone has thought about the future repository layout
yet (I haven't). I think that sharing the repository did not cause any
big problems in the past - there were only very few merge conflicts in
non-Dolphin code that I had to fix. However, that might change when
every project moves to frameworks at its own pace.

The parts of kde-baseapps are not completely independent, however.
Several apps and the FolderView plasmoid depend on lib/konq, but if
that was made a "Framework" of its own that any app can use, then one
could consider splitting the kde-baseapps repository.

>> 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 ;-)
>
> Heh, impossible! Or not possible without a huge amount of work.. What is
> probably easier (and still a huge amount of work) is making a QML view that
> works with the models in Dolphin.
>
> As for a tree view, there is no such thing in QML, but it can be created by
> nesting ListView components.
> Grouping is in QML! It's called "section" there:
> http://qt-project.org/doc/qt-5.1/qtquick/qml-qtquick2-listview.html#section.property-prop

Thanks for the hint. But it seems to me that "Sections" are only
available in ListView, and not in GridView (which would be more
interesting from a Dolphin point of view)?

>> 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?
>
>
> Well, you've done an amazing job in making Dolphin more performant and your
> predecessor (Peter) had done an amazing job in creating a new and better
> model structure without the shittyness of QModelIndex. However, much of the
> optimisation you've done now is what you basically get for free if you use a
> ListView or GridView in QML. That stuff only loads what has to be visible so
> it already has lazy loading build in. It might be very painful, but if you
> do want to go in the QML route for dolphin then you should port back to QAIM
> and QModelIndex probably with KDirModel.

Thanks for the nice words!

The best long-term solution is probably to go into the QML direction,
but this will probably have to be done by someone != Frank. When Peter
quit (which I still consider a very sad thing for KDE) and asked me if
I wanted to take over, I very much doubted if I would be able to do
it, considering that I can't really spend as much time on Dolphin as
he did. And then, during the 4.9 beta/RC cycle, I received around 50
mails from bugs.kde.org per day for quite some time, this was really
insane, and I would probably have gone completely mad if it was still
like that. But I think the strategy to focus on bug-fixing and small
improvements has worked out quite nicely and is also appreciated by
most users. BTW, we have only 119 open bug reports at the moment (and
10 of these are about version control plugins, which are not part of
Dolphin itself). I think that this is quite remarkable if you compare
that with other KDE and non-KDE free software projects, and also if
you consider that we had more than 300 at some point last year.

But even if the "bug fixing and small improvements" strategy works
well for some time (especially after the major changes that came with
Dolphin 2.0 and 2.1), there is not doubt that there will be a time
when bigger changes are needed to make the application future-proof. I
hope that I won't be the last one to notice when everyone thinks "it
sucks so much that Frank doesn't port Dolphin to QML" and I'll give
way to someone else in time.

>> 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.
>
>
> Hey psst, you will never get is as fast as the natural sorting that my
> brother made ;)

That could very well be, but our "natural sorting" really must have
some kind of locale-awareness.

> Anyway, any optimisation there would be awesome! That is still one of the
> areas where you can notice dolphin being really busy for a few seconds.

Agreed.

The other major area that can keep the CPU busy for a few seconds in
large folders is the layouting in Icons/Compact View, where we
determine in advance for every item how much space will be needed for
its text. I think that Aaron raised this issue in an unrelated
discussion on the Frameworks ML quite some time ago, when I was still
busy finding my way in the maintainer role and also in the parts of
the source code that I had not worked with earlier, and I had not
really started testing how it works with hundreds of thousands of
files.

Layouting the text for every single file (most of which will never be
shown in the view) is clearly a very wasteful process. However, if we
want a flexible number of lines in Icons View, then a "lazy layouting"
that delays these calculations until they are really needed will
require rather intrusive changes in the layouting code, and I think
that it's not quite trivial to ensure that the scroll offset and its
maximum value are always correctly updated while scrolling through all
items. I'm planning to investigate this at some point, but I'm not
sure if it will work for Dolphin 4.12.

Cheers,
Frank