K(Abstract)FileItemActionPlugin

[Frank Reininghaus]

Hi Albert,

thanks for your comments.

2013/6/8 Albert Astals Cid:
> El Divendres, 7 de juny de 2013, a les 17:40:29, Frank Reininghaus va
> escriure:
>> Hi everyone,
>
> Hi
>
>> 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.
>
> Another disadvantage:
>  * I as a user do: apt-get install amazing-dolphin-plugin and will not see it
> working. Next thing i do is i file a bug against the amazing-dolphin-plugin
> developer. Two things can happen then:
>     * amazing-dolphin-plugin developer gets angry because he feels he is being
> treated as a "criminal" when he is not and stops developing the amazing-
> dolphin-plugin

I never said that I consider plugin developers as "criminals". Most of
them are certainly doing very useful work. I just think that the great
power that comes with KAbstractFileItemActionPlugins also comes with
great responsibility: code that is executed in the actions() method
(that is the one that gets called every time the context menu is
opened) must be written with great care, and the most important thing
that any plugin developer must do IMHO is to make sure that no code in
this method has the potential to freeze or crash. Unfortunately, past
experience has shown that some people don't care much about these
issues, which is why I'm looking for a good solution now.

>     * amazing-dolphin-plugin developer learns he can use some kind of
> kconf_update magic or something to enable his plugin unconditionally (at the
> end you still have to store a setting somewhere so it can be tricked on "make
> install", "apt-get install" or watehver time)
>
> That's a loss-loss situation and not enough blogs can fix that.
>
> Now, we can probably mitigate this disadvantage together with the one you
> mentioned being more proactive on installed plugins. You can keep in your
> config files the list of installed plugins, and on each dolphin start check it
> against the currently installed plugins (this shall be hopefully be fast
> enough even you don't need to do it blocking for showing the window) , if some
> new plugin has been installed, you proactively show the user a window saying
> "Hi dude, we've seen you've installed a new plugin[s], do you want to enable
> it?".

In principle, we could do that, but I think that a dialog shown at
startup might be considered too instrusive. If someone starts Dolphin,
I guess that he/she wants to see the view with the files and
directories as quickly as possible, and everything that prevents that
might be considered an annoyance. Note that the dialog would be shown
for *every* Dolphin user when upgrading to KDE 4.11 - I think that
there are few KDE installations without Activities out there.

Moreover, it would not be sufficient to show a Dialog in Dolphin. It
would also be needed in Konqueror, but only when started in or
switching to file management mode. Also in FolderView, but I'm not
sure if the Plasma people would be happy if such a dialog would be
shown at Plasma startup.

Finally, checking at startup is not sufficient. Plugins can also be
installed while the applications are running, so one would have to
check if there are new plugins every time the context menu is opened.
This isn't a big problem implementation-wise, but I'm not sure if
showing a notification dialog instead of the context menu when the
user right-clicks a file is a clean and user-friendly solution.

An alternative might be to append an entry "Configure Services..." to
the context menu, which takes the user right to the "Services" section
of the settings dialog. In the use case you described above, the user
who wonders why the newly installed plugin isn't shown would hopefully
see this entry, click it, and be happy. But this could also be
considered annoying. Maybe there could be a checkbox in the "Services"
settings with which this could be disabled.

Cheers,
Frank