From kde-panel-devel Wed May 29 05:46:32 2013 From: "Frank Reininghaus" Date: Wed, 29 May 2013 05:46:32 +0000 To: kde-panel-devel Subject: Re: Review Request 110684: Do not show the "File to activity linking plugin" in context menus by def Message-Id: <20130529054632.13651.71945 () vidsolbach ! de> X-MARC-Message: https://marc.info/?l=kde-panel-devel&m=136980642125111 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0407223536632694518==" --===============0407223536632694518== Content-Type: multipart/alternative; boundary="===============1957736700340934947==" --===============1957736700340934947== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110684/ ----------------------------------------------------------- (Updated May 29, 2013, 5:46 a.m.) Status ------ This change has been marked as submitted. Review request for Plasma and Ivan Čukić. Description ------- The "File to activity linking plugin" performs some operations on startup that are not guaranteed to succeed fast. Therefore, it can freeze the host application if the user tries to open the context menu. IMHO, this is not acceptable for a plugin that is enabled for every KDE user by default, even those who do not use the plugin, or even do not use Activities at all. Well, I think it is questionable if potentially blocking operations should be done in a context menu plugin at all, but I see that there might be no other way to do it which would be equally user-friendly way for people who do use the plugin to link files to activities. Therefore, I propose this compromise which makes sure that only users who consciously enable the plugin are exposed to its potential drawbacks. Depends on my earlier kdelibs request https://git.reviewboard.kde.org/r/110625/ , which did not get any objections so far. From my point of view, the only alternative is a Dolphin-internal solution that either disables the plugin unless it has been enabled explicitly or just bans it from the context menu. This would be easier for me and require less code changes, but I believe that the solution that I'm proposing here is preferable because it is more transparent and gives both users and plugin developers a choice. This addresses bug 314575. http://bugs.kde.org/show_bug.cgi?id=314575 Diffs ----- src/workspace/fileitemplugin/FileItemLinkingPlugin.cpp 82cb8db Diff: http://git.reviewboard.kde.org/r/110684/diff/ Testing ------- Thanks, Frank Reininghaus --===============1957736700340934947== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit

This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110684/

This change has been marked as submitted.

Review request for Plasma and Ivan Čukić.

By Frank Reininghaus.

Updated May 29, 2013, 5:46 a.m.

Description

The "File to activity linking plugin" performs some operations on startup that are not guaranteed to succeed fast. Therefore, it can freeze the host application if the user tries to open the context menu. IMHO, this is not acceptable for a plugin that is enabled for every KDE user by default, even those who do not use the plugin, or even do not use Activities at all. Well, I think it is questionable if potentially blocking operations should be done in a context menu plugin at all, but I see that there might be no other way to do it which would be equally user-friendly way for people who do use the plugin to link files to activities. Therefore, I propose this compromise which makes sure that only users who consciously enable the plugin are exposed to its potential drawbacks.

Depends on my earlier kdelibs request https://git.reviewboard.kde.org/r/110625/ , which did not get any objections so far. 

From my point of view, the only alternative is a Dolphin-internal solution that either disables the plugin unless it has been enabled explicitly or just bans it from the context menu. This would be easier for me and require less code changes, but I believe that the solution that I'm proposing here is preferable because it is more transparent and gives both users and plugin developers a choice.

Bugs: 314575

Diffs

src/workspace/fileitemplugin/FileItemLinkingPlugin.cpp (82cb8db)

--===============1957736700340934947==-- --===============0407223536632694518== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel --===============0407223536632694518==--