Submit a runner to KDE

[Aaron J. Seigo]

On Sunday 09 August 2009, Dan Vratil wrote:
> So please could some of you here take a look on the runner, tell me if it
> even worth commiting and maybe show me the right path to follow?

great to see this in playground; let's get it into shape for 4.4! :)

i'm not sure where it should end up, though: with kopete, in kdebase-
workspace, in kdeplasma-addons? hmm... to me, it seems like one of those 
desktop integration bits that really _ought_ to be there. right now it's 
kopete specific, and would likely remain that way if shipped with kopete. if 
we put it into kdebase/workspace/plasma/runners/ that might result in people 
working on support for other IM apps too :)

as for the code, some comments:

     const QStringList& ids = m_contactData.keys();

that is slow: it iterates over m_contactData and creates a new QStringList. 
use a QHashIterator or a QHash::const_iterator instead (depending on which 
semantics you prefer, the Java or the C++ style)

    QDBusReply<QStringList> reply = 
QDBusConnection::sessionBus().call(request);

that is synchronous, which means the rest of krunner will stall until that 
happens. worse, if kopete isn't running this will just simply fail and the 
runner won't work.

what should probably happen is:

* the runner should watch for kopete's dbus interface being available (see 
QDBusConnectionInterface::serviceOwnerChanged)

* when prepare() is called if kopete is around, an async call to kopete should 
be made to collect the contacts

* when teardown() is called, clear this data


what would be really quite nice is the ability to update matches while they 
are "live", so if a contact goes offline while the match is showing the match 
should be changed to reflect this change in status as well . hmm.... that 
would probably require an updateMatch[es]() call in AbstractRunner?

it is unfortunate that we're shipping all this data back and forth between 
kopete and krunner, too. what would _really_ make sense is an addition to 
kopete's dbus API that takes a string and returns a list of matching UUIDS, 
possibly another one that returns a full set of their properties? that would 
certainly limit the amount of data being duplicated on both ends, though it 
would mean more d-bus activity during krunner searching.

in any case, the updating of contacts should stop when teardown() is called 
and only be happening once prepare() is called to keep krunner as quiet as 
possible when not in use.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Software
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20090817/ce65262e/attachment-0001.sig