question about AbstractFileManagerPluginPrivate::eventuallyReadFolder()

Sven Brauch mail at
Sat Oct 7 09:37:24 UTC 2017

On 07/10/17 11:27, René J. V. Bertin wrote:
> QObject::thread() returns "the thread in which the object lives." That's a 
> little vague but that means " the thread in which the object was created", no?
> In this case that would cause a DirectConnection to be used, which supposedly 
> isn't right for signals sent from another thread.

The thread the object lives in is the thread it is created in, until it
is moved _from that thread_ to another thread with moveToThread().

> The issue is reproducible (only the project toplevel directory is loaded when 
> using Qt::QueuedConnection explicitly). It turns out though that the finished and 
> entries signals are sent from code that appears to be running on the thread that 
> created the FileManagerListJob instance. That explains why a DirectConnection is 
> safe (but not why a QueuedConnection isn't?)

I didn't look in this case, but a thread is not necessarily running (and
actually executing) an event loop. That is required for queued signals.

> @Sven: didn't you remark that the project also imports the build directory? I 
> saw that happen printing the payload of the entries signals. I guess we could 
> apply the project filter in addJobItems(), no?

I think something along these lines would help, yes.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the KDevelop-devel mailing list