[Nepomuk] Dolphin and NepomukCore

[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. It was the compile time
problem that I wasn't sure how to deal with.


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

Lets see if Peter/Sebastian respond.


>
> Best regards,
> Frank
>



-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20121015/e9691f12/attachment.html>