plasma workspace integration for akonadi

[Heena Mahour]

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
> version
> > > > 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
> worthwhile.
> > 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
> light
> 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.
> (Please
> correct me if I'm wrong.)
>
> That leads me to a migration path which involves kdepimlibs as the first
> step,
> so we can actually get at the data in akonadi. Which also means that a
> custom
> 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
> but
> > 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.
> whether
> > 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
> usually
> > 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.
> --
> sebas
>
> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>



-- 
-Heena
Season of kde'12 participant
Google Summer of Code 2013
Delhi College of Engineering(COE),India
http://about.me/heena.mahour
http://heenamahour.blogspot.in
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140210/05f5e74e/attachment.html>