On Friday, 2013-06-14, Pali Rohár wrote: > Kontact has summary kpart plugin which showing new (unread) > mails. But I do not know if it can be extended without patching > it... > > @Kevin, do you know if this is hardcoded for kmail? Or is there > API for using kontact summary plugin (adding new mails)?
Each application that has support for being part of the Kontact shell can provide a summary plugin. Such a plugin can then of course whatever means it wants to use to get the necessary information from its core. > Kmail has own taskbar icon and notifications reporting directly to > KDE plasma. > > There is some dbus signal (but again kmail specific) > org.kde.kmail /KMail org.kde.kmail.kmail.unreadCountChanged > > And I do not know nothing more about notifications for new mails. > > @Kevin, is there something other? It used to use the KNotify API but has probably switched to a more advanced API by now. While you could target that in a KDE plugin, it might be worth to investigate to target the cross-desktop notification API instead. KDE, like many other FOSS desktop providers, implements that specification and integrates notifications coming through that API into its normal notification flow. Look for a D-Bus service called org.freedesktop.Notifications > > Notifications? Providing some kind of a persistent identifier > > so that Kontact can "attach" mails to e.g. events in a > > calendar? Perhaps that's impossible without pretending to be > > an akonadi backend, in which case it's out of a table, but > > still worth a discusssion. > > If it is not necessary, I would like not to use akonadi. And I do > not know if there is some Kontact API which not using akonadi... Two different aspects of the task. The Kontact plugin API for the sub task of integrating into the Kontact meta- application or shell. The Akonadi API for the sub task of accessing addressbook data and, if that is desired, calendar data (e.g. accepting event invitations). > > I agree with Kevin's mail later in this thread where he is > > strongly in favor of async interfaces -- these are harder to > > write, but provide huge benefits. > > Here with async interfaces, do you mean to use Qt signals/slots > for jobs and not to use blocking exec() functions? If you have an exec() method you are usually already dealing with an asynchronous interface that is made to behave synchronously through the exec() call. But yes, asynchronous usually means that you start an operation and the result is delivered through signal. As mentioned above, some of those APIs have exec() methods that allow to write code that looks like synchronous usage. This, however, is not without risk. It can easily result in unexpected re-entrance-like situations, because the code looks like it is blocking on exec() when in reality it is re-entering the event loop and could end up in the same place again. One of the most painful maintenance burdens in old KDE code is to get rid of those nested event loops. Anyone having the chance to stay asynchronous from the get-go is highly encouraged to do so :) Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
