<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="http://git.reviewboard.kde.org/r/110625/">http://git.reviewboard.kde.org/r/110625/</a>
</td>
</tr>
</table>
<br />
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for kdelibs.</div>
<div>By Frank Reininghaus.</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Currently, all KAbstractFileItemActionPlugins which are installed are embedded into file management-related context menus unless the user explicitly disables them in the settings.
This becomes problematic if the plugin's actions() method executes code that is not guaranteed to return very fast - the user will notice that the host application freezes without even knowing that one of the plugins is the culprit.
In a perfect world, all code executed by plugins would be perfect and the problem would not exist at all. Unfortunately, the world is not perfect, and there are plugins which do things that succeed most of the time, but cause trouble sometimes: https://bugs.kde.org/show_bug.cgi?id=314575
It seems that what Activities is trying to achieve cannot easily be solved using a safer approach which is equally user-friendly for Activities users. On the other hand, I don't think that people who do not use the plugin at all should suffer from the freezes caused by the plugin, so I thought that we could give developers of plugins which execute some "fragile" code the chance to declare that only users who enable the plugin explicitly in the settings should see the plugin's actions in their context menu.
For further information, please see https://bugs.kde.org/show_bug.cgi?id=314575.
Unfortunately, the original author of KAbstractFileItemActionPlugin chose to not add a d-pointer, so I had to use a hack to make it work.
I have patches that make this work:
kactivities (includes another change that fixes a build failure for me): http://paste.kde.org/749834/
kde-baseapps: http://paste.kde.org/749846/</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Deleted kservicemenurc -> Activities not shown in Konqueror/Dolphin context menus, and the plugin is shown as disabled in the settings.
Enabled the plugin in the settings dialog of either Konqueror or Dolphin -> plugin is shown, and disabling it in the dialog hides it again.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>kio/kio/kabstractfileitemactionplugin.h <span style="color: grey">(6af7396)</span></li>
<li>kio/kio/kabstractfileitemactionplugin.cpp <span style="color: grey">(07f15f6)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/110625/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>