在 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
