[Nepomuk] Dolphin and NepomukCore

[Frank Reininghaus]

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