On Mittwoch, 19. Juni 2013 20:21:41 CEST, Sune Vuorela wrote:
On 2013-06-17, Frank Reininghaus <[email protected]> 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
