On Mon, Oct 15, 2012 at 7:16 PM, Peter Penz <[email protected]> wrote:
> Hi Vishesh and Frank, > > just a few short thoughts from my side, as I wrote KFileMetaDataWidget. I > was never really happy with the implementation of KFileMetaDataWidget, as > it needs to deal with getting meta-data by 2 different approaches (Nepomuk, > Strigi) and 3 possible settings-configurations: > 1. Nepomuk off + indexing off > 2. Nepomuk on + indexing off > 3. Nepomuk on + indexing on > > (there is also an option 4 with Nepomuk disabled on compiletime, but in > this case KFileMetaDataWidget does not show any content) > > There would be a lot of room to improve the existing code even with the > need to support all configurations, but personally I'd prefer another > approach: I did not have a look at the new Nepomuk2-API, but if I remember > correctly I heard there should be an asynchronous API for getting metadata? > > If this is the case and if there is a someone brave who suggests to reduce > the 3 options above to only 2: > 1. Nepomuk on + indexing off > 2. Nepomuk on + indexing on > *) > I would like to do that. It would make the code a lot simpler. But then I don't want to be on the receiving side of all the hate. I get enough of that already. Maybe we could have a runtime check to see if Nepomuk is running and accordingly use the new widget / KFileMetadataWidget? > ... then I'd suggest to: > - Mark KFileMetaDataWidget from kdelibs as deprecated > - Create a new version of KFileMetaDataWidget in Nepomuk only using the > new Nepomuk2 API (no usage of Strigi anymore). > - Within Nepomuk create a fallback for getting the metadata in case if > indexing is disabled. As the Nepomuk-API for getting the metadata is > asynchronous this also could be done in a custom process like done in the > fileindexer. If in the future some replacement for Strigi might be used in > Nepomuk, then this would not affect any applications anymore, but only > Nepomuk itself. > The future is here :D. We won't be depending on Strigi for 4.10. > My impression during the last years was that most users that disabled > Nepomuk did it because of the indexing-service. Of course turning on > Nepomuk without indexing still has some impact on memory, but currently > working on a slow notebook with enabled Nepomuk + disabled indexing I could > not face any performance drawback. Still of course removing that option > will most probably result in controversial discussions, but personally I'd > prefer that a decision would be done for the "traditional desktop" like > e.g. in Plasma Active instead of hiding ourselves behind options ;-) > > Some random thoughts about what should also be checked when writing an > improved version of KFileMetaDataWidget: > > - Currently metadata-labels like "width:", "height:"... are translated > "manually" within KFileMetaDataWidget. This was a hack to provide users > with translated labels... It would be great if Nepomuk would provide an API > to get a translated string of a property. > Right. This is something really important, cause I'm not sure if any of the ontologies actually get translated. > > - KFileMetaData also provides a way to manipulate metadata (e.g. the > rating, comments and tags). But this is currently somehow hardcoded in the > KFileMetaDataWidget. Probably in the longterm Nepomuk could provide a > factory-method to get a kind of "manipulation widget" for a metadata. > +1 Exactly what I had in mind. > I won't have much time for more detailed discussions about this topic, but > in case if you have a question related to KFileMetaDataWidget please feel > free to contact me. > I mainly just wanted to run it by you. You did design most of the KFileMetadataWidget stuff. I wouldn't want to go around deprecating stuff without consulting the author. > Best regards, > Peter > > *) Of course there is still the compile-option of having no Nepomuk at > all, but in this case the current implementation of KFileMetaDataWidget > does not show anything at all too. > > > 2012/10/15 Frank Reininghaus <[email protected]> > >> 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. >> >> >> > 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! >> >> Best regards, >> Frank >> > > -- Vishesh Handa
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
