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 _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
