plasma workspace integration for akonadi

Kevin Krammer krammer at kde.org
Tue Feb 18 16:25:51 UTC 2014


On Monday, 2014-02-10, 13:47:45, Sebastian Kügler wrote:
> On Friday, February 07, 2014 19:25:55 Kevin Krammer wrote:
> > On Friday, 2014-02-07, 18:26:20, Marco Martin wrote:

> > > * *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.)

You are right and Akonadi itself is already buildable with Qt5.

> 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.

Good point!

> Otherwise, basic status information is something that should be done using
> Statusnotifier items.

Is that something like the device notifier?
I always get confused which is which since I have battery and network in a 
separate panel but other things like devices and mixer in the "tray".

> > 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.

The "workspace integration" idea was/is mostly about monitoring and control, 
i.e. seeing which resources you have, what their state is, being able to "put 
them on hold", etc.
I.e. a replacement and more advanced successor for AkonadiTray.

Search folders would be for data, but yes, hopefully Baloo will make that work 
extremely well.

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/20140218/2ce2c773/attachment.sig>


More information about the Plasma-devel mailing list