K(Abstract)FileItemActionPlugin

[Frank Reininghaus]

Hi,

2013/6/14 Thomas Lübking:
> On Donnerstag, 13. Juni 2013 16:36:31 CEST, Frank Reininghaus wrote:
>>
>> Hi,
>>
>> sorry for the late reply.
>
>
> And sorry myself for similar reasons ;-)
>
>>> 2013/6/10, Frank Reininghaus:
>>
>> time explaining users why reassigning the bug away from Dolphin makes
>> sense ("No, that's impossible. I don't use Activities at all!").
>
>
> Ah, there we go from abstract to particular.
> That's most likely a menu hanging because kactivityd does not reply?
> We had similar. libkactivities should meanwhile cache values, but i'm not
> sure whether that holds in this case as well.
> Since you block for dbus, here's a QnD fix proposal:
>
> QDBusConnection::sessionBus().interface()->setTimeout(500);
>
> This will constrain the timeout to 500ms - still quite some, but the default
> is usually 25 seconds!
>
> It however affects all dbus calls from dolphin (so if you've sth. very
> crucial where the reply actually could take longer, you'd have to
> temporarily raise it again)
>
>>> 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 ...
>>
>>
>> Interesting idea, but this approach looks like implementing it without
>> introducing new bugs is not quite trivial.
>
> See above, if it's (only) about dbus hangs, you could constrain them this
> way (either in general or just around suspicious calls to popups etc.)
>
>
>> I would certainly appreciate it if there was mandatory review for all
>> modules which are released as part of the KDE SC!
>
>
> Actually, the problem here is (in the first place) not so much the kactivies
> code quality, but the synchronous interface - dbus can block for random
> reasons, not necessarily caused by or related to the other end of the line
> (eg. flooding. i don't know about the particular issue, but synchronous dbus
> usage is a general issue in GUI threads)

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.

Either one can guarantee that some code will be executed successfully
very fast, or it cannot be used in a context menu plugin's actions()
method. It's as simple as that. But maybe I'm a bit biased here, I'm
just the stupid idiot who gets all the user complaints and bug reports
after all ;-)

Cheers,
Frank