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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
