<br><br><div class="gmail_quote">On Mon, Oct 15, 2012 at 7:16 PM, Peter Penz <span dir="ltr"><<a href="mailto:peter.penz19@gmail.com" target="_blank">peter.penz19@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Vishesh and Frank,<div><br></div><div>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:</div>


<div>1. Nepomuk off + indexing off</div><div>2. Nepomuk on + indexing off</div><div>3. Nepomuk on + indexing on</div><div><br></div><div>(there is also an option 4 with Nepomuk disabled on compiletime, but in this case KFileMetaDataWidget does not show any content)</div>

<div><br></div><div>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?</div>

<div><br></div><div>If this is the case and if there is a someone brave who suggests to reduce the 3 options above to only 2:</div><div>1. Nepomuk on + indexing off</div><div>2. Nepomuk on + indexing on</div><div>*)</div>
</blockquote><div><br>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.<br> <br>Maybe we could have a runtime check to see if Nepomuk is running and accordingly use the new widget / KFileMetadataWidget?<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>... then I'd suggest to:</div><div>- Mark KFileMetaDataWidget from kdelibs as deprecated</div><div>- Create a new version of KFileMetaDataWidget in Nepomuk only using the new Nepomuk2 API (no usage of Strigi anymore).</div>

<div>- 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.</div>
</blockquote><div><br>The future is here :D. We won't be depending on Strigi for 4.10.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>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 ;-)</div>

<div><br></div><div>Some random thoughts about what should also be checked when writing an improved version of KFileMetaDataWidget:</div><div><br></div><div>- 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.</div>
</blockquote><div><br>Right. This is something really important, cause I'm not sure if any of the ontologies actually get translated.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><br></div><div>- 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.</div>
</blockquote><div><br>+1 Exactly what I had in mind.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>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.</div></blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>Best regards,</div>
<div>Peter</div><div><br></div><div><div>*) 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.</div>

</div><div class="HOEnZb"><div class="h5"><div><br></div><div><br></div><div><div class="gmail_quote">
2012/10/15 Frank Reininghaus <span dir="ltr"><<a href="mailto:frank78ac@googlemail.com" target="_blank">frank78ac@googlemail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Hi Vishesh,<br>
<br>
2012/10/15 Vishesh Handa:<br>
[...]<br>
<div><div>>> > The problematic part is that of the KFileMetadataWidget. It currently<br>
>> > resides in kdelibs/kio, and uses Nepomuk1. We cannot port it to Nepomuk2<br>
>> > cause of a cyclic dependency (nepomukcore depends on kdelibs, and with<br>
>> > the<br>
>> > port kdelibs will depend on nepomukcore).<br>
>> ><br>
>> > One idea that we had was to write a new version of the KFileMetadata<br>
>> > widget,<br>
>> > which would reside in the nepomuk-widgets repository. This new version<br>
>> > could<br>
>> > hopefully move away from simple (Label: Value) pairs and maybe try to<br>
>> > show<br>
>> > the data in a more visual manner. We do have certain feeders which push<br>
>> > photos for various resources such as albums, artists, and tvshows.<br>
>> ><br>
>> > Another reason why we should move away from the KFileMetadataWidget is<br>
>> > because it loads the file metadata in another process. This was done<br>
>> > because<br>
>> > the widget also works without Nepomuk and relies on strigi which is<br>
>> > known to<br>
>> > crash a lot.<br>
>> ><br>
>> > By using a separate process, one doesn't use the internal cache, and has<br>
>> > to<br>
>> > query the database.<br>
>> ><br>
>> > Any opinions?<br>
>><br>
>> On the one hand, replacing KFileMetaDataWidget with an alternative<br>
>> that does not need the "read meta data in another process" workaround<br>
>> for Strigi's crashiness sounds like a good idea to me. On the other<br>
>> hand, I think that the "works without Nepomuk enabled" feature is<br>
>> something that some people would really miss. There are users who do<br>
>> not use Nepomuk, and I can already see lots of bug reports coming if<br>
>> those users cannot see any meta data in the Infomation Panel any more.<br>
>> Would it be possible to have the new widget read the meta data<br>
>> on-demand from the file if the user has disabled Nepomuk in the system<br>
>> settings?<br>
><br>
><br>
> With Nepomuk's current architecture that would be hard. Though considering<br>
> that I eventually do plan to deprecate Strigi, it might be required.<br>
><br>
> How about for now we conditionally compile either the KFileMetadataWidget or<br>
> this new widget? That way you would have the exact functionality when<br>
> Nepomuk is disabled.<br>
<br>
</div></div>But this would mean that the decision which widget to use will be<br>
taken at compile time. However, the user has the freedom to disable<br>
Nepomuk in the System Settings at run time.<br>
<br>
Maybe one could determine at run time if Nepomuk is enabled or not and<br>
then decide which widget to use, but I don't believe that this would<br>
be a good solution either. This would not make maintenance easier, and<br>
it might also confuse users because it might not be obvious why they<br>
get the 'old' or the 'new' widget.<br>
<div><br>
>> > Also, I would like some help with the building of this widget. I'm not a<br>
>> > particularly great designer.<br>
>><br>
>> Well I'm not a designer either, but a first step might be to just<br>
>> replicate the functionality and design of KFileMetaDataWidget. For the<br>
>> majority of the meta data, I think that showing "Label: Value" pairs<br>
>> makes sense.<br>
><br>
><br>
> Looking into KFileMetadataWidget, I see a LOT of code. And I'm not sure how<br>
> others would feel about duplicating it. Hence this thread.<br>
><br>
> The KFileMetadata widget currently supports the following -<br>
><br>
> 1. Fetching file stat info - file size and some other details. These can be<br>
> fetched directly from Nepomuk, but the code relies on kio since one cannot<br>
> be sure the file will be indexed, and more importantly in the case of<br>
> directories, will all its subfiles/subfolders be indexed.<br>
><br>
> 2. Grouping the results - You can group certain keys together, like the<br>
> width and height of an image<br>
><br>
> 3. Hiding certain properties by default, and allowing this to be user<br>
> configurable.<br>
><br>
> 4. Asynchronous Loading - This is done by the separate process, but we will<br>
> need to use another thread.<br>
><br>
> If there are no objections, then I'll make a near duplicate, by copying the<br>
> code wherever possible.<br>
<br>
</div>I've never worked with KFileMetaDataWidget myself, so I don't really<br>
have a better idea, sorry!<br>
<br>
Best regards,<br>
Frank<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><span style="color:rgb(192,192,192)">Vishesh Handa</span><br><br>