K(Abstract)FileItemActionPlugin

[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
    * 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?".

This should make my disadtage go away and your upgrade problem too since the 
list of installed plugins will be empty and you'll ask for all the existing 
ones.

What do you think?

Cheers,
  Albert

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