K(Abstract)FileItemActionPlugin

[Chao Feng]

在 2013年6月10日 星期一 19:42:36，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?

We can learn from how Firefox and Chrome handle this problem. Some idea:
* When Dolphin found a newly installed plugin, show a dialog asking if users 
want to enable it.
* If Dolphin crashed, at the next start up, show a dialog of all enabled 
plugin, asking users to disable some/all of the plugins. Just like browser  
session manager does for web pages. 

Chao Feng

> 
> 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