Nepomuk Metadata Extractor moved to KDE Review

[Jörg Ehrichs]

Hi Sebastian,

2012/11/8 Sebastian Kügler <sebas at kde.org>:
> * As far as I can see, QWidget-related bits and "service-related" bits are
> split, so we're able to drop another ui on top of it for Plasma Active without
> much effort. (Even if the UI is a single knob =)) (Correct me if I missed a
> few points.)
>

Yes this was the idea behind all of it. Each program that want's ti use this can
decide to either reuse the available ui or just the the easy to use
single parts.

It is possible to use the plugin based structure for searching/
metadata fetching and
than doe whatever someone wants with the data (a big QVariantMap) and also reuse
the actual Nepomuk abstraction, that understands such a QVariantMap
structure and
allows to easily throw such data into Nepomuk.

Conquirere actually uses this to integrate the search/select/save
frontend better into
the application. The same can easily be done by plasma or other apps
that want to
use Web Metadata search and/or Nepomuk integration based on key=value pairs

>
> * The browser integration is a very cool feature. It's nice that it supports
> Konqueror, Chrome and Mozilla/NPAPI on multiple platforms. I suppose it works
> with both Rekonq and Konqueror?
>

The browser part is is bit "experimental" and should all of this go into KDE SC
i will leave the browser part in extragear. The problem here is that in order to
build the NPAPI part the "kinda complicated" firebreath development enviroment
is necessary.

reKonq support is currently not possible, because it does not have a plugin api
available at the moment.

>
> * Is there any support for images planned? I think especially additional
> geolocation information could be really useful (also for other resource types,
> by the way. In Plasma Active the user can set a location, it would be cool if
> we could retrieve additional info through Nepomuk about the location, and
> thereby being able to relate it to other data, think "Photos taken at current
> location" =)
>

Extraction geo information from images/files is the responsibility of
the fileindexer
Also "all fotos from location lat/long" isn't part of this.

What could be added is a way to extend the fetcher to allow ot get information
about a specific geo lat/long. Like lat/long is the City London or
something like it.
In order to save such additional information, we might need to add a
new ontology.

>
> * One UI issue I see is that it installs a toplevel systemsettings module,
> while it should be under "Desktop Search", so part of the Nepomuk KCM (which
> is also not great at all, UI-wise :/). I could imagine the primary knobs
> integration the service into the system a bit like this:
> [...]
> If we want to add it to our default install by 4.11 (which I support!), those
> should be fixed.
>

I know the current solution is more temporary, but integration into the Nepomuk
KCM isn't so easy either. Nonetheless Vishesh wanted to change this part anyway
and some mails ago in this discussion there was the idea to combine the MetaData
Extractor and Nepomuk.

In this step we will come up with a better looking configuration KCM
and this would
also allow me to reuse the nepomuk System Tray parts to give
information about the
current progress.

So unless this is a stopper to go extragear I would like to wait for
this change for the
possible 4.11 integration.

>
> * the binary name for metadataextractor should probably be nepomuk-
> metadataexractor or somesuch (matching other related binaries, easier to find
> if uses on the commandline).
>

I think I will rename everything to Nepomuk WebFetcher and than also
adapt the commandline
program with it.

>
> * Is the scripting API documented or is it planned?
>

Yes it is documented in the doxygen output. I will put the same
information to techbase later on too.

>
> * You're shipping pre-generated Nepomuk headers it seems,[...]
>

This is fixed, now all these files will be generated from cmake.
And have a build switch, so this can be avoided after the first generation.

>
> * Coding Style
>
> spacing after if statements:if(bla) becomes if (bla
> spacing between arguments: foo(firstArg,secondArg) becomes foo(firstArg,
> secondArg)
>

Whupps, I thought I've already changed QtCreator to respect kdelibs
coding style.
Seems I've missed these parts. I'll fix that.

>
> * Licensing
>
> Please consider using the KDE e.V. clause in your licenses, it makes the legal
> side a bit more future proof (it's clearer about the (L)GPL successor). You
> can find those on http://techbase.kde.org/Policies/Licensing_Policy From what
> I can see, licensing overall pretty much complies otherwise, so that's just a
> suggestion.

I'll change this too.

Cheers and thanks for the long input,
Joerg