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
