[Nepomuk] Dolphin and NepomukCore

[Peter Penz]

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
*)

... 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.

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.

- 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.

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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20121015/04e1224f/attachment.htm>