Dolphin and Baloo

[Vishesh Handa]

On Tuesday 04 February 2014 15:45:53 Frank Reininghaus wrote:
> Hi,
> 
> 2014-02-04 Vishesh Handa:
> > I just fixed all the issues you mentioned.
> 
> cool, thanks! I think we're getting there. I noticed just two more things:
> 
> 1. There is a HAVE_NEPOMUK left in src/search/dolphinsearchbox.cpp. I
> guess the #ifdef'ed code should just be removed?
> 

Not entirely sure. Will look more into it.

> 2. About this code in KFileItemModelRolesUpdater::rolesData():
> 
> #ifdef HAVE_BALOO
>     if (m_balooFileMonitor)
>         m_balooFileMonitor->addFile(item.localPath());
> 
>     // We never fill the Baloo roles over here since that would require
>     // us to block by spawning a local event loop. Instead we call a slot
>     // to fill the values later
>     QMetaObject::invokeMethod(this, "applyChangedBalooRoles",
>                               Qt::QueuedConnection, Q_ARG(QString,
> item.localPath()));
> #endif
> 
> (a) This will always invoke applyChangedBalooRoles and thus start a
> Baloo::FileFetchJob, even if no Baloo roles are shown at all. We could
> just include that statement in the "if" block to prevent that, right?
> 

Fixed.

> (b) Is there a reason to use a QMetaObject invocation for calling
> applyChangedBalooRoles()? Since that function just starts the job, it
> should finish quite fast, right?
> 

Right. Fixed it.

> (c) Unless I'm overlooking something, it looks to me like
> rolesData(KFileItem) invokes applyChangedBalooRoles(QString), which
> will then finally trigger applyChangedBalooRolesJobFinished(KJob*).
> The latter function then calls rolesData(KFileItem) again. This looks
> like an infinite recursion to me. It won't cause a crash or block the
> GUI because two of the recursive calls are asynchronous, but it will
> make Dolphin use 100% of one CPU core permanently. Or am I missing
> something here?
> 

You're absolutely right.

I've changed it based on what you recommended, but I'm not too sure why that 
works.

> Cheers,
> Frank

-- 
Vishesh Handa