K(Abstract)FileItemActionPlugin

[Thomas Lübking]

On Mittwoch, 19. Juni 2013 20:21:41 CEST, Sune Vuorela wrote:
> On 2013-06-17, Frank Reininghaus <frank78ac at googlemail.com> wrote:
>> Yes, it can block for random reasons, and this is why making D-Bus
>> calls in the code that is executed before the context menu is shown is
>> unacceptable IMHO.
>
> I agree with the problem. But the issue is to *fix* kactivities to not
> do something insane.
Fixing kactivitiesd to not hang is orthogonal to Franks problem.

Of course it should be fixed if broken anyway, but: everytime you perform a sync dbus call or other I/O, you block the GUI. This can cause issues on your side (your problem), the bus (bus problem? system loaded?), or the other side (not responding, also holds for network or HDD)

The problem is that dbus is increasingly not seen as I/O but as funny API since, luckily, Qt makes its usage so simple.
You would never consider to download some video from youtube whenever the user attempts to open a popup, but it's the same problem.

> If I was a plugin developer here, I would of course think my plugin
> should be enabled by default and thus in my ctor call
> setEnabledByDefault(true)

I would suggest to leave the path of plugin enabling as solution asap - it's not a solution at all.

The plugin can initially work fine and great. And then, after a month or so, you get a "k-ac-ti-what?" update - alongside a dozen others - and suddenly it breaks.

Joe User does not think:
"Oh, yes. This is the activities plugin that blocks on popup opening as it makes a synchronous dbus call to kactivitiesd - let's ping the kactivitiesd process and see if it's hung. No? Wait: may still be dbus itself, can i qdbus?"

Joe User thinks:
"Crappy dolphin does not react and now i cannot hide my fapfolder before my girlfriend returns. I'm screwed AND IT'S ALL FRANKS FAULT!!!" and then reports a bug that will not be fixed - esp. not in time.
His GF finds his fapfolder, the relation breaks apart and she even deleted the folder "AND IT'S ALL FRANKS FAULT!!!!"

And there's Franks problem.

-> my 2¢
---------

Synchronous I/O in the GUI thread can, at least post-init, be reasonably considered a bug.

So if I had to choose, i'd declare it as bug, stress that in the plugin tutorial/whatever, point plugin devs to Qt's pending reply system and set the dbus timeout to a value so low (25ms?) that even multiple calls will not utterly block the GUI - or even set the timeout to "virtually impossible" to cause the plugin developers problems for sure. So they notice this is not ok and find an async imlpementation.

The only issue is of course that the plugin can simply re-raise the timeout, but frankly: if someone figures his sync I/O was explicitly disabled this way, eventually contacted the kfm group or found the explanation in some official tutorial and still re-enables it, he's just a jerk and I had no worries blacklisting the plugin and when it's attempted to load, present the user a dialog that pretty much explicitly states /why/ it is blacklisted - maybe offer to unblacklist to shoot himself.

Cheers,
Thomas