K(Abstract)FileItemActionPlugin

Frank Reininghaus frank78ac at googlemail.com
Thu Jun 13 15:36:31 BST 2013


Hi,

sorry for the late reply.

2013/6/10 Thomas L├╝bking:
> 2013/6/10, Frank Reininghaus:
>
>> 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.
>
> Well, that's the concept of plugins.

Yes, but if a plugin is installed and enabled on every KDE user's
machine, then it effectively becomes an unreviewed part of the host
application.

> What makes me wonder why it should not be possible to assign the bugs
> for them to the original author.

Of course that's possible, but that does not help much if the plugin
author decides to ignore the reports until I finally get really angry
and threaten to blacklist his plugin. Moreover, I sometimes had a hard
time explaining users why reassigning the bug away from Dolphin makes
sense ("No, that's impossible. I don't use Activities at all!").

> If it's a crash, there should be a backtrace ending in the plugin lib, yesno?
> If it hangs everything, i'd wonder whether it was an option to
> establish a watchdog in a second thread, ie. when opening the popup or
> in general executing plugin code of that matter (esp. such which will
> run in the GUI thread) start a timer in a secondary thread and if the
> GUI thread does not return within a second or so (what's quite a time
> to open a context menu) abort() and maybe lauch a "kdialog" process
> telling the user: "here, some crappy plugin takes ages to respond and
> possibly blocks the GUI thread forever - please see the debug dialog
> for details and no: apparently this code cannot be run off-thread.
> solution: get rid of that plugin and also file abug against the
> author")

Interesting idea, but this approach looks like implementing it without
introducing new bugs is not quite trivial.

>> such changes anyway. So I'll just hope that people who write plugins
>> will be more careful in the future
> No?
>
>> at least if the plugin is part of a core KDE module
> Part of, or loaded by?

AFAIK, kactivities is a hard build time dependency for kde-workspace
and can thus be considered a core KDE module.

> For a substandard stock plugin, enforce a better review process

I would certainly appreciate it if there was mandatory review for all
modules which are released as part of the KDE SC!

Regards,
Frank




More information about the kde-core-devel mailing list