On Friday 14 June 2013 21:17:26 Kevin Krammer wrote: > 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. >
Yes, I found it (read another my mail). There is virtual function createSummaryWidget() in KontactInterface::Plugin. > > 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 > Hm, I will look at org.freedesktop.Notifications notification. > > > 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. > I know problems of using local QEventLoop, possible race conditions or recursive funcions loops... Also there is problem if somebody (qt library) delete object where exec() is calling... > 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 -- Pali Rohár pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
