On Thu, Oct 18, 2012 at 3:15 PM, Frank Reininghaus <[email protected] > 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
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
