K(Abstract)FileItemActionPlugin

[Thomas Lübking]

2013/6/10, Frank Reininghaus <frank78ac at googlemail.com>:

> 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.
What makes me wonder why it should not be possible to assign the bugs
for them to the original author.
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")

> 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?
For a substandard stock plugin, enforce a better review process and in
doubt blacklist it until that improved or call it to be either
properly maintained or abandoned and dropped.

Cheers,
Thomas