Hi, 2012/10/15 Vishesh Handa: > > > On Mon, Oct 15, 2012 at 5:55 PM, Frank Reininghaus > <[email protected]> wrote: >> >> Hi Vishesh, >> >> 2012/10/15 Vishesh Handa: >> [...] >> >> > The problematic part is that of the KFileMetadataWidget. It currently >> >> > resides in kdelibs/kio, and uses Nepomuk1. We cannot port it to >> >> > Nepomuk2 >> >> > cause of a cyclic dependency (nepomukcore depends on kdelibs, and >> >> > with >> >> > the >> >> > port kdelibs will depend on nepomukcore). >> >> > >> >> > One idea that we had was to write a new version of the KFileMetadata >> >> > widget, >> >> > which would reside in the nepomuk-widgets repository. This new >> >> > version >> >> > could >> >> > hopefully move away from simple (Label: Value) pairs and maybe try to >> >> > show >> >> > the data in a more visual manner. We do have certain feeders which >> >> > push >> >> > photos for various resources such as albums, artists, and tvshows. >> >> > >> >> > Another reason why we should move away from the KFileMetadataWidget >> >> > is >> >> > because it loads the file metadata in another process. This was done >> >> > because >> >> > the widget also works without Nepomuk and relies on strigi which is >> >> > known to >> >> > crash a lot. >> >> > >> >> > By using a separate process, one doesn't use the internal cache, and >> >> > has >> >> > to >> >> > query the database. >> >> > >> >> > Any opinions? >> >> >> >> On the one hand, replacing KFileMetaDataWidget with an alternative >> >> that does not need the "read meta data in another process" workaround >> >> for Strigi's crashiness sounds like a good idea to me. On the other >> >> hand, I think that the "works without Nepomuk enabled" feature is >> >> something that some people would really miss. There are users who do >> >> not use Nepomuk, and I can already see lots of bug reports coming if >> >> those users cannot see any meta data in the Infomation Panel any more. >> >> Would it be possible to have the new widget read the meta data >> >> on-demand from the file if the user has disabled Nepomuk in the system >> >> settings? >> > >> > >> > With Nepomuk's current architecture that would be hard. Though >> > considering >> > that I eventually do plan to deprecate Strigi, it might be required. >> > >> > How about for now we conditionally compile either the >> > KFileMetadataWidget or >> > this new widget? That way you would have the exact functionality when >> > Nepomuk is disabled. >> >> But this would mean that the decision which widget to use will be >> taken at compile time. However, the user has the freedom to disable >> Nepomuk in the System Settings at run time. >> >> Maybe one could determine at run time if Nepomuk is enabled or not and >> then decide which widget to use, but I don't believe that this would >> be a good solution either. This would not make maintenance easier, and >> it might also confuse users because it might not be obvious why they >> get the 'old' or the 'new' widget. > > > You're right. > > From a runtime point of view - I can make the widget work even when Nepomuk > is disabled. That should not be a big problem.
OK, that sounds good! Best regards, Frank _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
