K(Abstract)FileItemActionPlugin

[Albert Astals Cid]

El Dilluns, 10 de juny de 2013, a les 15:56:16, Frank Reininghaus va escriure:
> 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. 

Was thinking yesterday that maybe we want to involve some of the usability 
guys? Explain the problem and see if they come up with a nice idea that has 
the best of both worlds?

Cheers,
  Albert

> 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