K(Abstract)FileItemActionPlugin

[Frank Reininghaus]

Hi Albert,

thanks for the quick reply.

2013/6/9 Albert Astals Cid:
> El Diumenge, 9 de juny de 2013, a les 09:22:10, Frank Reininghaus va escriure:
>> 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.
>
> Well, that's why used the quotes :D You're basically treating all plugin
> writers as if they write crashy code just because someone did once, so you're
> treating them all as "bad guys".
>
> Note i totally understand your point of view, it sucks to have your program
> crash just because someone coded their actions() method unsafely.

It was indeed an *extremely* frustrating experience for me to find out
that code which had (to my knowledge) been written without any kind of
review could be installed and run on the machine of every Dolphin user
out there, and that the bug reports which were piling up were simply
ignored for several months.

My proposal here aimed to make sure that such a thing never happens
again, but I see now that solving this without creating new annoyances
for other people is less trivial than I thought. I'm still not sure if
a dialog that notifies people about new plugins is the right way to
solve it, and now is not the best point in the release cycle to make
such changes anyway. So I'll just hope that people who write plugins
will be more careful in the future, at least if the plugin is part of
a core KDE module, and thus going to be installed everywhere.

Thanks again and best regards,
Frank