On Thursday, September 12, 2013 16:19:18 Martin Graesslin wrote:
> On Thursday 12 September 2013 15:51:55 Aaron J. Seigo wrote:
> > On Thursday, September 12, 2013 15:26:50 Marco Martin wrote:
> > > in general to c++ it's maybe slightly clunkier, since one has to call
> > > model->
> > >
> > > >da
On Thursday 12 September 2013 15:51:55 Aaron J. Seigo wrote:
> On Thursday, September 12, 2013 15:26:50 Marco Martin wrote:
> > in general to c++ it's maybe slightly clunkier, since one has to call
> > model->
> > >data(role) and then try to convert the qvariant.
> >
> > (perhaps it may have some
Heh, Aaron woke up :)
So, this is what is going to be done (90% finished already):
** API mostly stays the same. **
Info, Consumer:
===
In the back:
- all instances of both classes share a backend that syncs the data with the
server
In the front:
- expose the synced data thro
On Thursday, September 12, 2013 15:26:50 Marco Martin wrote:
> in general to c++ it's maybe slightly clunkier, since one has to call model-
> >data(role) and then try to convert the qvariant.
>
> (perhaps it may have some api to ease fetch data from c++)
>
> on QML... would be awesome :D
i’d be
On Thursday 12 September 2013, Aaron J. Seigo wrote:
> as an added bonus, it would be possible to make multiple instances of the
> model share the data behind the scenes: so no matter how many models are in
> use there would only ever be one copy of the data. things like
> Consumer::listActivities
On Friday, September 6, 2013 21:25:19 Ivan ÄukiÄ wrote:
> In the current activities api, we were tried to make a synchronous api to
> something that is async - dbus.
after sending my last email which was really just a knee-jerk response to the
question being posed i stepped back for a
On Saturday, September 7, 2013 00:20:47 Ivan ÄukiÄ wrote:
> > is for KActivities::Info ?
> > I have to actually think more about it, but just at a glace i would leave
> > the
> > info api as it is now but not creatable, but to be asked with a kjob.
>
> I'd rather then have a KJob* fetchPropertie
> is for KActivities::Info ?
> I have to actually think more about it, but just at a glace i would leave
> the
> info api as it is now but not creatable, but to be asked with a kjob.
>
I'd rather then have a KJob* fetchProperties() than having a kjob create
the instance - especially since KJob's A
On Friday 06 September 2013, Ivan Čukić wrote:
> Hi all,
>
> In the current activities api, we were tried to make a synchronous api to
> something that is async - dbus.
is for KActivities::Info ?
I have to actually think more about it, but just at a glace i would leave the
info api
Hi all,
In the current activities api, we were tried to make a synchronous api to
something that is async - dbus.
It works for the basic use-cases, but it is not pretty. There are a few
methods that are going away in the new version (the previously deprecated
ones), so I've been thi
Am Dienstag, 13. April 2010 08:31:22 schrieb Chani:
> hey, ivan wanted me to tell you guys that he's moved the nepomuk activities
> stuff into kdereview. :)
>
There are some i18n() calls, but I don't find a Messages.sh...
--
Burkhard Lück
___
Plasma-de
hey, ivan wanted me to tell you guys that he's moved the nepomuk activities
stuff into kdereview. :)
it's the API we developed at tokamak - for letting apps query things like the
current activity, and for letting workspace things (ie, plasma) manage them.
--
This message brought to you by eevi
12 matches
Mail list logo
