[Nepomuk] Dolphin and NepomukCore

[Vishesh Handa]

On Mon, Oct 15, 2012 at 4:44 PM, Frank Reininghaus <frank78ac at googlemail.com
> wrote:

> Hi Vishesh,
>
> thanks for your message!
>
> 2012/10/11 Vishesh Handa:
> > Hey everyone
> >
> > Dolphin is one of the last major applications that still needs to be
> ported
> > to Nepomuk2. I would appreciate it if someone migrated the code. Porting
> is
> > quite simple and there is a mini guide on the techbase [1]
>
> Emmanuel already volunteered to do the port (see the recent review
> request).
>

That's great!


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


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


> Best regards,
> Frank
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>



-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20121015/76a63179/attachment.htm>