[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: KActivities library optimizations
From:       Ivan =?utf-8?B?xIx1a2nEhw==?= <ivan.cukic () kde ! org>
Date:       2012-09-06 6:35:36
Message-ID: 2445594.oDNcgIEW1f () drako
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


> more libraries means harder to use (have to know the more about the design
> to know which library to use and when).
> 
> i think a dep on nepomuk is just fine as long as nepomuk's depencies are
> limited .. if they aren't, then it can be an issue.

The reason why I disagree are the apps that just want to use the 
ResourceInstance class to report the opened urls. The most those will need is 
- RI class and knowing the current activity. I think this covers the most 
applications out there. And for those, I'd like libkactivities to be a Qt-only 
library. And with KF5, it might even be possible. (currently, only kdebug and 
klocalizedstring are used from kdelibs, and qtcore and qtdbus from Qt).

Listing activities, doing fancy queries etc. is needed only in a small number 
of applications (mostly workspace stuff, or the clients that want to do 
something more complex - kate, kdevelop or similar)

> i'm not clear on what the dependency on qtsql is for? (sorry .. hopefully
> you can explain in more detail)

Yup. If you recall, at first we had a nepomuk backend for storing the desktop 
events and resource scoring. It turned out that speed-wise, nepomuk is not 
really suitable for the queries like 'get me all events that are produced by 
this app in this activity and target that resource'* which is understandable 
since Nepomuk is a graph database and the query above is a poster child of 
relational dbs - filtering one table.

For that, events are stored in sqlite and only the calculated scores are 
pushed in nepomuk. In order to make the data-models featureful, it would need 
to access the sqlite database as well.

* needed for calculating the score

> if data models are meant to be "the" way to interact with activities, which
> could well be a valid approach, then having a separate lib also won't buy us
> much as everything will use the models library anyways.

As I said, it would be /the/ way for kwin, plasma, and similar. Not for the 
rest.

> and yes, mega bonus points for suddenly not worrying about sync/async :)

:)

-- 
Money can't buy happiness, but neither can poverty.
  -- Leo Rosten

["signature.asc" (application/pgp-signature)]

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[prev in list] [next in list] [prev in thread] [next in thread]