[Nepomuk] Dolphin and NepomukCore

[Vishesh Handa]

On Mon, Oct 15, 2012 at 7:16 PM, Peter Penz <peter.penz19 at gmail.com> 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 <frank78ac at googlemail.com>
>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20121015/55408f4f/attachment.htm>