--001a11c1e980cd4dac04e6ae8706 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 18, 2013 at 9:05 PM, Frank Reininghaus 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/ > --001a11c1e980cd4dac04e6ae8706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Wed, Sep 18, 2013 at 9:05 PM, Frank Reininghaus <frank78ac@googl= email.com> wrote:
Hi Mark,
Hi Frank,

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

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 playin= g 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 par= ts.
>
> Is there anyone working on this?

I guess there is no real plan for the Qt5/KF5 transition yet, b= ut 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 del= iver
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 t= here, 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 mi= nd 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.

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 peopl= e think?

Well, you've done an amazi= ng job in making Dolphin more performant and your predecessor (Peter) had d= one an amazing job in creating a new and better model structure without the= shittyness of QModelIndex. However, much of the optimisation you've do= ne 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 laz= y loading build in. It might be very painful, but if you do want to go in t= he 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<= br> "naturally". I tried that some time ago, and it did reduce the to= tal
time required for sorting quite considerably. It works because our
"merge sort" implementation is able to make use of (partially) so= rted
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 a= reas where you can notice dolphin being really busy for a few seconds.=A0

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://quick= git.kde.org/?p=3Dkonsole.git&a=3Dshortlog&h=3Db820dbf715b9c07f3dede= a7bbc018d7a92647505
http://quickgit= .kde.org/?p=3Dkonsole.git&a=3Dcommit&h=3Da83db71590a9faa85d2daee330= c1f9d2ff958bb2
htt= ps://git.reviewboard.kde.org/r/111937/

--001a11c1e980cd4dac04e6ae8706--