<br><br><div class="gmail_quote">On Mon, Oct 15, 2012 at 5:55 PM, Frank Reininghaus <span dir="ltr"><<a href="mailto:frank78ac@googlemail.com" target="_blank">frank78ac@googlemail.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,<br>
<br>
2012/10/15 Vishesh Handa:<br>
[...]<br>
<div><div class="h5">>> > 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></blockquote><div><br>You're right.<br><br>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.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><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></blockquote><div><br>Lets see if Peter/Sebastian respond.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best regards,<br>
Frank<br>
</blockquote></div><br><br clear="all"><br>-- <br><span style="color:rgb(192,192,192)">Vishesh Handa</span><br><br>