plasma workspace integration for akonadi
heena393 at gmail.com
Mon Feb 10 14:31:04 UTC 2014
apart from re-implementation of lion mail , what about the other tasks I
mentioned , these are fine? these will also require akonadi client library
of kdepimlibs .
On Mon, Feb 10, 2014 at 6:17 PM, Sebastian Kügler <sebas at kde.org> wrote:
> On Friday, February 07, 2014 19:25:55 Kevin Krammer wrote:
> > On Friday, 2014-02-07, 18:26:20, Marco Martin wrote:
> > > On Friday 07 February 2014 16:28:20 Kevin Krammer wrote:
> > > > The GSOC idea referenced below is not about data at all, it is about
> > > > state.
> > > >
> > > > Akonadi state information and control works via D-Bus, so it would be
> > > > possible to do a client for that without linking to libakonadi-kde.
> > > >
> > > > This was just brought up as an option, since Plasma/workspace
> > > > development
> > > > and KDEPIM libs development are currently not using the same Qt
> > > > and
> > > > potentially will not during the GSOC period.
> > >
> > > my concern is:
> > > * is this worth, as opposed to waiting for kdepimlibs?
> > I mostly brought this up as an options, it might or might not be
> > Using D-Bus directly might allow to only transfer information that is
> > needed, on the other hand making a QML adaptor for things like
> > Akonadi::AgentInstanceModel will be faster and easier to code.
> > Obviously also a difference in dependencies if that matters.
> > > * is accessing those dbus functions something that kdepimlibs doesn't
> > > provide?
> > No. But kdepimlibs obviously involves more C++ classes.
> > > * *if* a Qt5 kdepimlibs was available, would this way be
> > > preferrable anyways?
> > My understanding is that there is a frameworks branch in kdepimlibs which
> > at some point was fully build-able. No idea what the current status is.
> That's my status as well. I hope the upcoming PIM sprint will shed some
> on this. I'm pretty sure though that we're looking at at least another two
> workspace releases until PIM has been ported to KF5.
> (Note, that still doesn't mean that Akonadi has to have been ported, if I
> understand the architecture well, it should be entirely possible to have
> Akonadi(Qt4) used by kdepimlibs/5 (and even KMail4) at the same time.
> correct me if I'm wrong.)
> That leads me to a migration path which involves kdepimlibs as the first
> so we can actually get at the data in akonadi. Which also means that a
> pim-status-lib will be replaced very quickly, making it quite a waste to
> implement it at high-enough quality.
> Otherwise, basic status information is something that should be done using
> Statusnotifier items.
> > I've repeated that specific GSOC idea for a couple of years now, either
> > there were no takers or they didn't convince us that they could
> > successfully do it.
> > I didn't re-add the idea again, mostly because of the lack of interest
> > also because of the bad timing for this year (focus on different Qt
> > versions).
> > Since it is a "old" idea it might also have to be reevaluated, e.g.
> > it fits into the current or future concepts of our workspace offerings,
> > etc.
> > The only reason this was listed as KDEPIM idea was that Plasma was
> > consistently filling all the GSOC slots it could get while KDE PIM
> > had some to spare.
> > This is almost 100% user interface and user interaction work.
> Hoping that the stuff in kdepimlibs is now up to the job (searchfolders
> working well enough, for example), yes.
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
> Plasma-devel mailing list
> Plasma-devel at kde.org
Season of kde'12 participant
Google Summer of Code 2013
Delhi College of Engineering(COE),India
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Plasma-devel