Feature Freeze KDE 4.11

[Frank Reininghaus]

Hi,

2013/5/22 Emmanuel Pescosta:
> Hello Frank,
> am I allowed to add some features to the KDE 4.11 feature plan? (2 weeks
> more time :)
>
> Maybe:
> * Timsort

As I said earlier (I think): it does not make much sense that every
application implements its own sorting function. The only reason why
Peter implemented a custom sort function at all is that it was not
obvious how a member function could be used as the comparison
function. This issue is resolved now - if you had not implemented the
parallel sorting last year, I would have removed the custom sorting
code by now.

I'm not 100% happy about the idea to add a few hundred lines of code
for yet another custom sorting implementation that has to be
maintained in the future. But I don't want to be blamed for wasting
lots of CPU cycles all around the world and thus harming the
environment, so I'm not completely opposed to it either.

But from my point of view, the following conditions must be met:

(a) The sort function can be used as a drop-in replacement for
qStableSort, std::sort and friends. Other apps can possibly re-use the
code then. Moreover, less modifications in KFileItemModel are needed -
making the code in that class more complex to further improve the
performance by a small amount is the wrong way to go IMHO. Finally, it
makes possible future changes of the sort algorithm easier - who knows
if you will come up with yet another new sorting idea for KDE 4.12 ;-)

(b) There are unit tests which ensure that the sort algorithm works correctly.

(c) There are benchmarks which show that Timsort is considerably
faster than using some library function like std::sort or the
qStableSort clone that we have now.

> * middle clicking on archive files in dolphin does not open them in a new
> tab

Is fine from my point of view!

> * New folder with selected items (Only if you agree with it, because
> scrolling to the newly created folder is impossible with a plugin
> implementation)

To be honest, I don't see a big need for this feature. AFAIK, it
hasn't even been requested at bugs.kde.org yet (and even if it was, I
would still be skeptical). If only very few users want this feature,
how many of them will be bothered because the view doesn't scroll to
the new folder? Is that really worth making the code in some of
Dolphin's core classes more complex for this feature then?

Note that Ark's "Create archive" plugin has the very same issue, and
I'm not aware of any complaints about it.

Writing and maintaining software is not about putting as many features
or as many lines of code as possible inside. All that code has to be
maintained in the future, and it will cause trouble at some point
(like when there is a bug in the DolphinView which is completely
unrelated to the feature and the new functions make it a little harder
to understand what's going on).

> * Folder Panel Context Menu patch

I haven't been able to look into this issue in detail yet. Moreover,
reading the diff at paste.kde.org is not exactly easy.

But most importantly, I wish you had said something *before* you
started working on this. How can I evaluate the idea without bias if I
know that you have spent lots of time on this already? I really
appreciate all your efforts, and I don't want to frustrate you.

> * The tabwidget, tabbar and tabpage patch

Looks much better than the first version, but I haven't really looked
at every detail yet. And to be honest, reviewing patches of this size
in my free time is rather challenging. I see that such a refactoring
cannot be split into smaller parts easily, but I think that just
asking if such a refactoring makes sense and then coming up with such
a huge patch some time later (yes, you did send me an intermediate
state at some point, but I think that the bulk of the work was already
done then) is not the best way to work on software in a team.

I think the better approach would be to first discuss how to approach
the problem in general, i.e., in what classes the code should be
split, what the relationships between them are, where the different
methods of DolphinMainWindow are moved, etc. All this *before* any new
code is written.

Nonetheless I will try to look at the patch until next week. But if
the community expects from me that I review further patches of this
size, which have been made without any prior in-depth discussion, in
the future, then I must say that I cannot continue to maintain
Dolphin.

Best regards,
Frank