[Nepomuk] Dolphin and NepomukCore

[Frank Reininghaus]

Hi,

2012/10/15 Vishesh Handa:
>
>
> On Mon, Oct 15, 2012 at 5:55 PM, Frank Reininghaus
> <frank78ac at googlemail.com> 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.

OK, that sounds good!

Best regards,
Frank