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 _______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
