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. It was the compile time problem that I wasn't sure how to deal with. > > >> > Also, I would like some help with the building of this widget. I'm > not a > >> > particularly great designer. > >> > >> Well I'm not a designer either, but a first step might be to just > >> replicate the functionality and design of KFileMetaDataWidget. For the > >> majority of the meta data, I think that showing "Label: Value" pairs > >> makes sense. > > > > > > Looking into KFileMetadataWidget, I see a LOT of code. And I'm not sure > how > > others would feel about duplicating it. Hence this thread. > > > > The KFileMetadata widget currently supports the following - > > > > 1. Fetching file stat info - file size and some other details. These can > be > > fetched directly from Nepomuk, but the code relies on kio since one > cannot > > be sure the file will be indexed, and more importantly in the case of > > directories, will all its subfiles/subfolders be indexed. > > > > 2. Grouping the results - You can group certain keys together, like the > > width and height of an image > > > > 3. Hiding certain properties by default, and allowing this to be user > > configurable. > > > > 4. Asynchronous Loading - This is done by the separate process, but we > will > > need to use another thread. > > > > If there are no objections, then I'll make a near duplicate, by copying > the > > code wherever possible. > > I've never worked with KFileMetaDataWidget myself, so I don't really > have a better idea, sorry! > Lets see if Peter/Sebastian respond. > > Best regards, > Frank > -- Vishesh Handa
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
