on models, QML and Nepomuk

[Shantanu Tushar Jha]

Hi,

On Fri, Nov 16, 2012 at 8:11 PM, Marco Martin <notmart at gmail.com> wrote:

> Hi all,
>
> I am doing a big refactor for the metadata models in plasma active, used
> to do
> nepomuk queries.
>
> this made me think about some things:
> * we all agree we want to use nepomuk more

* we also want to use more qml to write user interfaces
> * to display nepomuk data in qml, basically means: to have a model that
> shows
> results from a query
> * i would really like to avoid both exposing sparql to qml and doing some
> weird javascript binding of the nepomuk query api, this is really stuff
> that
> who writes QML should *not* see
>
> now, both writing qabstractitemmodels and nepomuk query and result display
> are
> two things that besides requiring quite some boilerplate are quite easy to
> screw up.
>
> We already had a model, but since its query generation capabilities were
> quite
> basic, i already seen it forked somewhere else, duplicating all the bugs it
> had (hello mediacenter :p)
>

wrong, its not a fork, its just a small and media specific model (nothing
when compared to PA's metadatamodel) that does nepomuk queries and stores
the results in a list. Its only called metadatamodel as the name is pretty
nice ;)


> in the end what a model do, is basically map from the list of
> Nepomuk2::Query::Result that arrived to rows of the model, and format the
> data
> in a particular way depending from the role asked.
>
> right now the MetadataModel, in the branch mart/newMetadataModel of plasma-
> mobile is done this way:
>
> The model manages the query in a thread, splitting it in chunks (with
> limit)
> to be able to have lazy loading
>
> Everything specific is delegated to another class, QueryProviders, which
> base
> api is inplasma-
> mobile/components/metadatamodel/queryproviders/abstractqueryprovider.h
> it does the following things:
>
> * it sets a query, either Nepomuk2::Query::Query or sparql
>
> * it sets the mapping between role  indexes and role names
>
> * given a Query::Result and a role it formats it to the data to display
>
>
> this class is abstract, doesn't do anything, but is intended to be in a
> public
> library, to be subclassed, so in qml one can do, after registering from the
> c++ part the MyQueryProvider implementation:
>

This is a nice idea, flexibility++

>
> MetadataModel {
>         queryProvider: MyQueryProvider {
>                 //setting of custom properties that control the query
>         }
>         delegate: ...
> }
>

I hope one can also say this-

MetadataModel *model = new MetadataModel();
model->setQueryProvider(new MyQueryProvider());

i.e. to be able to use it from C++.


> it provides some default subclasses that have the functionality of the old
> multiple models in plasma active,
> simple query for resources (ie i want all resources that are images linked
> to
> a certain activity, with a certain mimetype)
> tagcloud type of model (either cloud of tags or any other property like
> file
> types, basically a simple group by, very useful for visualizations
> timeline: how many resources satisfy a criteria separed by year, month or
> day
>
> right now the work in that branch is around at 90% complete i think, still
> some things to decide like wether export in the library all the current
> queryprovider subclasses or how to nicely map to qml things like resource
> types (now there are some heuristics that go from/to things like nfo:Audio
> and
> the full uri)
>
>
> i would really love to have this in a place public for everyone, to be
> clear
> that for 99% of the needs of nepomuk in qml, use that. There still can be
> use
> cases for different reimplemented bindings, but if is just a simple
> listing of
> stuff, no need to duplicate bugs ;)
>
> It may be nepomuk-core? (since it has a library, so unsuited for
> kde-runtime)
>

Yes please, if this can go into nepomuk-core (however that will mean no
dependencies on Qt Declarative, not sure how thats gonna be handled), it
will be very easy for standalone applications like Plasma Media Center to
use it.

>
> anyways, as general concept.. opinions/comments?
>

The design, esp the QueryProvider bit is pretty nice, good job :)

>From PMC's PoV, all we need is a metadatamodel which can be used and
extended from pure C++ code[1]. From the design you discussed above, if
metadatamodel lives in neopomuk-core and can be instantiated from C++,
thumbs up!

[1] When this was not possible, we had to do stuff like this
http://quickgit.kde.org/?p=plasma-mediacenter.git&a=blob&h=740d2423a8ff5b8a4b65b1dc371161e81f99e964&hb=fbac7a7a1a147deac287709ee0cb002e7f1053fb&f=browsingbackends%2Fmetadatabackends%2Fabstractmetadatabackend.cpp(line
36)
If metadatamodel can be instantiated directly from C++, we won't need all
this :)


> Cheers,
> Marco Martin
> _______________________________________________
> Active mailing list
> Active at kde.org
> https://mail.kde.org/mailman/listinfo/active
>

Cheers,

-- 
Shantanu Tushar    (UTC +0530)
http://www.shantanutushar.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/active/attachments/20121116/cd8bdba0/attachment.html>