Porting dolphin to Qt5/KF5?

[Mark]

On Thu, Sep 19, 2013 at 11:31 AM, Frank Reininghaus <
frank78ac at googlemail.com> wrote:

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

Well yeah, then you'd have to make grouping in a listview and a gridview
for each group :)
QML required a bit different thinking, i learned that the hard way. In some
poor ascii art you'd get:

| ListView Group 1
| GridView
|---| |---| |---| |---| |---| |---|
|---| |---| |---| |---| |---| |---|
|---| |---| |---| |---| |---| |---|
| ListView Group 2
| GridView
|---| |---| |---| |---| |---| |---|
|---| |---| |---| |---| |---| |---|
|---| |---| |---| |---| |---| |---|
etc...


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

That is quite impressive!
For the model part. This is an interesting position where Dolphin is in
now. If memory serves me right, Peter initially created the new model
structure based of itemviews-ng for the reason faster, easier to maintain
and future proof for QML (which was a research project back then). Things
however turned out a bit differently. itemviews-ng didn't made it into Qt
and QML is still using the painful QAIM structures. Perhaps the QML
provided models use something more fancy, but you as an app developer are
left to use QAIM. This kinda brings back the same pain peter had with QAIM
only now it also requires porting the current structure back to QAIM.

I have no clue what could be best here, but i see a few possible solutions:
1. Port everything back to QAIM by using KDirModel en just go through that
pain.
2. Keep the current structure and create a whole new custom QAIM wrapper
(DolphinDirModel) which will be even more difficult at first since you have
to implement the odd parent child stuff from QAIM, but probably less work
then porting everything back.
3. A third possible way is something i've only "heard" of, i don't know
it's status or if it's even possible in Qt 5.2. There was some talk some
time ago about using different filesystem backends. There KIO would
possibly be a backend which would then allow you to use QFileSystemModel.
You also have QDirModel, but that is "obsolete". Again, i don't know the
status here or if it's even possible. Perhaps David can fill in the gap?

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