Review Request 110211: Make sure assistant actions live in the main thread

[Sven Brauch]

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


If there's no more complaints, then I'd submit this, I think it's okay. I'll adjust C++ before, of course.

- Sven Brauch


On April 27, 2013, 1:34 p.m., Sven Brauch wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/110211/
> -----------------------------------------------------------
> 
> (Updated April 27, 2013, 1:34 p.m.)
> 
> 
> Review request for KDevelop and Milian Wolff.
> 
> 
> Description
> -------
> 
> When implementing a problem resolution assistant for kdev-python,
> I noticed some very strange behaviour in the assistants API: actions
> would only be executed if they were added to the assistant in the
> actions() method (which is const, and should not create actions!),
> while creating them in the constructor of the assistant made them
> show up, but do nothing when triggered. The root of the problem turned
> out to be that the assistants are instantiated in the parse job,
> thus if you create the actions in the assistant's constructor, they
> will live in the parse job thread, not in the application main thread;
> the KAction's created from the assistant actions however would
> live in the main thread, because the method to convert iAssistantAction
> -> KAction is called from the main thread. Thus, connections wouldn't
> work correctly, as the thread of the receiver is not running an event loop.
> 
> The existing code, as said, smartly™ works around this problem by adding
> the actions to the assistant in the actions() method the first time
> it is called, which happens from the main thread too. This sucks,
> mainly because it cost me two hours to figure out why my actions wouldn't
> be executed when I created them in the constructor, but also because
> the API defines the function as const (which it should be), but the code
> just ignores this (by using const_cast). The real fun thing is that you
> *have* to do non-const things in a function defined by the API as const,
> because there's no other way to make it actually work.
> 
> This patch moves an action to the main window's thread when it is created,
> and also adds an assertion to make sure the connected objects reside
> in the correct threads.
> 
> I'm not very well-informed about Qt's threading stuff (or any threading
> stuff, really) yet, so this might well be the wrong approach to fix the
> issue. If it is, please let me know and suggest a better alternative.
> 
> I see one possible issue: When creating the actions in the constructor, way
> more actions than before will be created, increasing memory usage.
> This might be relevant or not, I don't know, it's probably not; but
> maybe someone can comment on that when reviewing.
> 
> 
> Diffs
> -----
> 
>   interfaces/iassistant.h 2a65e45 
>   interfaces/iassistant.cpp a102f27 
> 
> Diff: http://git.reviewboard.kde.org/r/110211/diff/
> 
> 
> Testing
> -------
> 
> The natural way (adding actions in the constructor) now works. Before I push this, I will refactor the code in cppsupport to create its actions in the constructor, too, instead of this const_cast mess which is currently there.
> 
> 
> Thanks,
> 
> Sven Brauch
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20130429/7e9d9ec6/attachment.html>