> 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 ju
On Wednesday, September 5, 2012 21:54:33 Ivan ÄukiÄ wrote:
> > > We need data models for it
> >
> > sounds good ...
>
> Now, since the models library (in order to skip data retrieval from kamd via
> d-bus*) will need to be linked to nepomuk (linked resources) and qtsql (for
> detailed even logs),
> > We need data models for it
> sounds good ...
Now, since the models library (in order to skip data retrieval from kamd via
d-bus*) will need to be linked to nepomuk (linked resources) and qtsql (for
detailed even logs), what do you think to make it a separate library -
libkactivities-datamo
> > Without the blocking. the hell would break loose - it wouldn't be
> > backwards
> > compatible and every kactivities client would need to be patched.
>
> according to lxr, that is:
>
> * plasma-desktop shell
> * activities DataEngine
> * activities Runner
> * powerdevil
> * plasma-mobile she
On Tuesday, September 4, 2012 16:19:52 Ivan ÄukiÄ wrote:
> > one thing i'm not a fan of with the new Consumer approach is that it is
> > impossible to know whether the code will block or not. it does a pre-fetch
> > and then cleverly blocks only if it hasn't received a reply yet. which
> > means
> one thing i'm not a fan of with the new Consumer approach is that it is
> impossible to know whether the code will block or not. it does a pre-fetch
> and then cleverly blocks only if it hasn't received a reply yet. which
> means there is no way to guarantee async behaviour when desired. as long
On Tuesday, September 4, 2012 11:28:22 Ivan ÄukiÄ wrote:
> I don't like the idea of having a simple requests like activity list
> or info with async api. This would be quite imitating for simple
> clients like loopless kio_activities, or file item plugin. It would be
> nicer to have something lik
On Tuesday 04 September 2012, Ivan Čukić wrote:
> > attempts to provide synchronous access. perhaps it would be better to
> > just drop the pretense of synchronicity in the API?
>
> I don't like the idea of having a simple requests like activity list
> or info with async api. This would be quite i
> sounds a lot less maintainable and in the long run less re-usable. i also
I agree, after some investigation, shared memory is a bit tedious to work with.
> wonder if using shared memory wouldn't simply move, rather than remove, lock
> contention for data population, etc.
There /would/ be less
On Monday, September 3, 2012 09:26:27 Ivan ÄukiÄ wrote:
> What do you think of the idea to go one step further, and instead of
> accessing the data via d-bus, to only use d-bus for signalling the changes,
> but to use QSharedMemory for actual data access (read-only from the
> library).
sounds a
Hi,
The latest master of libkactivities caches and pre-fetches some stuff like the
currentActivity, list of activities, list of running activities, activity
names and icons, to minimise the amount of d-bus related locks*.
What do you think of the idea to go one step further, and instead of acce
11 matches
Mail list logo
