Hi everyone, 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. 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/
