Global Presence

David Edmundson david at davidedmundson.co.uk
Thu Oct 6 00:25:50 UTC 2011


There's been a lot of dilly dallying wrt to how presence messages
should work in the CL, here's my design:

1) Ignore this stupid "status" identifier. It's near-impossible at a
global level, and tbh it never worked anyway it all appeared the same
to any other client.
   This means getting rid of "brb" and "do not disturb" as they didn't
do anything differently to "away" or "busy" respectively.2) Closely
tie in messages where the user has set presence messages, so a user
can set presences with the appropriate presence messages.
New UI (in progress).http://wstaw.org/m/2011/10/06/plasma-desktopDp1678.jpg
Clicking configure custom statuses opens shadeslayer's dialog to edit
new messages (see a previous email). Maybe this is a bit slow and we
need another system too but we can work on that later.
How it works technically: There is/will be a model of Tp::Presences
(both standard Online, Available etc) and ones loaded from the config
with messages. This model can be used everywhere to keep things global
and vaguely in sync. If a user enters a new presence message code
/should/ update the model then update the account presence. The
AccountButtons class can also use this model (someone wrote a QMenu
model class somewhere) The presence drop down may also display a
presence messages that isn't in the config/model, such as when the
status has been set by the now playing plugin (or elsewhere not KDE
related)
I don't think it's a perfect system, it's a bit tricky with all the
split resources and stuff but it should get us through 0.2?

Comments welcome.

Dave


More information about the KDE-Telepathy mailing list