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. > > > * 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?". > > In principle, we could do that, but I think that a dialog shown at > startup might be considered too instrusive. If someone starts Dolphin, > I guess that he/she wants to see the view with the files and > directories as quickly as possible, and everything that prevents that > might be considered an annoyance. Note that the dialog would be shown > for *every* Dolphin user when upgrading to KDE 4.11 - I think that > there are few KDE installations without Activities out there. > > Moreover, it would not be sufficient to show a Dialog in Dolphin. It > would also be needed in Konqueror, but only when started in or > switching to file management mode. Also in FolderView, but I'm not > sure if the Plasma people would be happy if such a dialog would be > shown at Plasma startup. I suggested a dialog because I'm old fashioned, nowadays we have all those nifty top notification bars, bubbles, etc that are less "In your face!" but still help, but i see your point, it may be a bit too much intrusive anyway. > Finally, checking at startup is not sufficient. Plugins can also be > installed while the applications are running, so one would have to > check if there are new plugins every time the context menu is opened. Well, as a user can "understand" that if I install a plugin for program "A" i need to restart program "A" (or even in the worst case reboot!), as a user what i can't understand is why installing a plugin for program "A" does nothing even after a reboot. > This isn't a big problem implementation-wise, but I'm not sure if > showing a notification dialog instead of the context menu when the > user right-clicks a file is a clean and user-friendly solution. > > An alternative might be to append an entry "Configure Services..." to > the context menu, which takes the user right to the "Services" section > of the settings dialog. In the use case you described above, the user > who wonders why the newly installed plugin isn't shown would hopefully > see this entry, click it, and be happy. But this could also be > considered annoying. Maybe there could be a checkbox in the "Services" > settings with which this could be disabled. Hmmm, what about a "Configure New Services..." if we detect there are new plugins? That entry would go away if you click on it or after a certain condition (dolphin restart/time after first show/time after detecting the new plugin/something). Cheers, Albert > > Cheers, > Frank
