[Nepomuk] Dolphin and NepomukCore

[Vishesh Handa]

On Thu, Oct 18, 2012 at 3:15 PM, Frank Reininghaus <frank78ac at googlemail.com
> wrote:

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

Sounds like a plan.


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

I'll take care of it.


> Best regards,
> Frank
>



-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20121018/0976d9e7/attachment.html>