Porting dolphin to Qt5/KF5?

[Mark]

On Wed, Sep 18, 2013 at 9:05 PM, Frank Reininghaus <frank78ac at googlemail.com
> wrote:

> Hi Mark,
>
Hi Frank,

I wasn't expecting such a long mail :) Replying inline.

>
> 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 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.

>
> 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


>
> 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.

>
> 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 ;)

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.

>
> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20130918/7febdcd8/attachment.htm>