plasma workspace integration for akonadi

Kevin Krammer krammer at kde.org
Fri Feb 7 18:25:55 UTC 2014


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.

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.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140207/ae144d98/attachment.sig>


More information about the Plasma-devel mailing list