K(Abstract)FileItemActionPlugin

[Frank Reininghaus]

Hi everyone,

I've recently implemented a mechanism that allows developers of
KAbstractFileItemActionPlugins to state that their plugin should not
be shown in file-management related context menus by default [1].

I've been thinking again about this approach again this week, and now
I think that it is not quite optimal, and that we should better just
disable all K(Abstract)FileItemActionPlugins unless the user has
enabled them explicitly. Please note that I'm not talking about simple
service menus (.desktop files) here, but only about those plugins that
execute some custom code when the context menu is opened.


1. Motivation

As I already said in the earlier review request, we received a lot of
bug reports about the Activities plugin freezing Dolphin. This is not
a problem any more because the plugin is now only used if the user has
explicitly enabled it [1].

However, I believe that there are also other plugins out there that
cause trouble. We often get bug reports like "Dolphin crashes when
right-clicking file" with no or rather unhelpful backtraces. I think
that they might be caused by buggy plugins (I remember that a user
once said that the crashes started after he installed some packages,
which supports this theory). I then always ask the reporters to try
and disable some of the "Services" in the settings dialog and see if
that fixes the problem, but unfortunately, I never got a useful reply
(people who are not willing to provide feedback should really not be
allowed to click "Report Bug" in DrKonqi, but that is off-topic here).
This is really frustrating.

IMHO, the best way to prevent that people who never explicitly stated
that they want to use a certain plugin (and who sometimes don't even
know that the plugin is installed on their system) suffer from its
bugs is to just disable all those plugins by default.


2. What I'm planning to do

I would like to revert the patches [1] and just replace the default
value "true" for the K(Abstract)FileItemActionPlugins by "false" in
Dolphin's and Konqueror's context menu (and also in the "Services"
page in the settings dialog, of course).


3. Advantages of this approach

(a) Users will never have to suffer from buggy plugins again, unless
they explicitly state that they want to use it. This is the most
important advantage from my point of view.

(b) Users who really want to use a plugin will probably enable it in
the settings, and then immediately try it by right-clicking a file. If
a crash occurs then, users will probably see a connection between the
plugin and the crash and hopefully tell the plugin developers about
it. I think that this makes it more likely that the quality of the
plugin will improve.

(c) The code becomes simpler.

(d) We get less useless crash reports.


4. Disadvantages of this approach

People who are regular users of a plugin already might wonder why the
plugin is missing when they upgrade to KDE 4.11, and they might not
know how to re-enable it.

I'll tell people about this change on my blog to make it less likely
that this causes problems, but I'm willing to help people who will
report missing plugins at bugs.kde.org or in the Dolphin forum.


If there are no objections, I will make this change before the Beta 1
tagging. Please note that I expect that people who do not agree with
my suggestion will help in the future with bug triaging.

Thanks and best regards,
Frank

[1]
https://git.reviewboard.kde.org/r/110625/
https://git.reviewboard.kde.org/r/110684/
https://git.reviewboard.kde.org/r/110685/