> 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
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
