question about AbstractFileManagerPluginPrivate::eventuallyReadFolder()

[René J.V. Bertin]

On Saturday October 07 2017 11:37:24 Sven Brauch wrote:

>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.

In this case it most certainly must be since it's the main thread. The documentation states that queued signals are executed when control returns to the eventloop that is supposed to handle the signal. I think that what happens here is that this is too late. Alternatively there would be an implicit underlying assumption that control has to return to the current thread from some other thread, and that might simply not happen in this case (if the FileManagerListJob doesn't run an event loop). I could check if the signals are ever delivered but now we know that a DirectConnection is appropriate there isn't really an urgent reason to understand why QueuedConnections don't work.

>> @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.

In fact the filter is already being applied deeper inside addJobItems(), I missed that before hitting send. I haven't yet seen evidence that the method is called with a baseItem that should be filtered out. I don't yet understand why that wouldn't happen.
One could just question why there is no default filter for "build;folders;exclude", or whatever the user choses as the project build directory(ies).

Cheers,
R.