K(Abstract)FileItemActionPlugin

[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.

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