[Nepomuk] Dolphin and NepomukCore

[Frank Reininghaus]

Hi Vishesh,

2012/10/15 Vishesh Handa:
>> > Maybe we could have a runtime check to see if Nepomuk is running and
>> > accordingly use the new widget / KFileMetadataWidget?
>>
>> The disadvantages of this approach are that we would have two widgets
>> to maintain, and that it is not transparent at first sight to the user
>> that enabling/disabling Nepomuk also decides whether he/she gets the
>> 'old' or the 'new' widget. I see a lot of potential for confusion,
>> subtle bugs, and bug reports that are unclear because we don't know
>> which widget is in use.
>>
>> Therefore I'm wondering how much work it would be to do the runtime
>> check in the new widget and let it use the new "Strigi replacement"
>> code retrieve the meta data from the file if Nepomuk is disabled?
>
>
> It would be certain amount of work. I'll have to make some kind of data
> provider class which would either fetch data directly from the database, or
> run the indexers. Plus, as a general rule, since the indexers are plugins
> and we do not control all o them. It would make sense to run them in a
> separate process.
>
> That would yield a fairly similar architecture to the one we have right now.
> Maybe slightly more complex, cause in the case when Nepomuk is enabled we
> would be using a thread, otherwise a process.
>
> I'm not too keen on doing that right now. I think I'll just code a simple
> replacement which only uses Nepomuk, and then start with the indexing
> information. I'm more concerned with having a good user experience when
> Nepomuk is enabled.

I fully understand that, but please understand that I'm trying to
provide a good user experience to *all* Dolphin users.

Would you be willing to accept patches for the new widget which enable
it to retrieve the information on demand if Nepomuk is disabled, if
someone volunteers to do that at some point? If that is the case,
having a runtime check in the Information panel and using the 'old'
widget from kdelibs as a fallback might be an acceptable temporary
solution.

By the way, since the Nepomuk2 port, we get crash reports like

https://bugs.kde.org/show_bug.cgi?id=308520
https://bugs.kde.org/show_bug.cgi?id=308523
https://bugs.kde.org/show_bug.cgi?id=308525

The bt of the last one shows that we're having trouble because
Nepomuk2::ResourceData::store() uses nested event loops. That causes
an unexpected recursion of
KFileItemModelRolesUpdater::resolveNextPendingRoles() because that
function invokes itself using a single shot timer. The problem is that
multiple recursed invocations of that function try to manipulate the
same QSets, so we end up with corrupted iterators and crashes.

IMHO, nested event loops are evil. This isn't the first time I see
them cause a crash. Even the API docs of KJob say that you shouldn't
do it:

http://api.kde.org/4.9-api/kdelibs-apidocs/kdecore/html/classKJob.html#a03c768fad2f9eef7b72b068b389c42ee

This must be fixed.

Best regards,
Frank