When we request global presence from contact list, it listens to currentPresenceChanged() signal. If current presence is different from requested presence, it sets requested presence to the current presence (from global presence). Therefore the contact list always displays current global presence while presence plasmoid always shows requested presence, which is not always correct as sometimes the requested presence cannot be set and account manager sets closest presence as the current. TL;DR - presence plasmoid should use the same algorithm contact list does - set requested presence, listen for currentPresenceChanged and if these two do not match, set requested presence to current presence.
Ideally, the algorithm should be moved to GlobalPresence itself; to onCurrentPresenceChanged() - if there's new current presence, set it as requested. That way we won't have each UI doing this.
I agree that these two are behaving differently, and that needs fixing. I don't agree with your conclusion. We shouldn't be calling requestPresence when the currentPresence changes.. that's really wrong. The code that is calling requestPresence() looks to be doing so accidentally because the model changes. Git log does not make it look deliberate, the message says it was changed to update the UI when external factors changed the presence, it does not say anything about it being to set the presence. Lets agree on what _should_ happen before we try and decide how to fix it. Pretend we have 2 accounts, One jabber : supports all statuses Local XMPP: doesn't support XA, will set currentPresence to away if requestedPresence is XA. requestPresence XA. What I understand you think should happen: - contact list shows "Away" - jabber account is away - local XMPP is away - presence applet shows away What I think should happen: - contact list shows XA - jabber account is XA - local XMPP is Away - presence applet shows XA (because everything should show the requestedPresence all the time)
I remember it was designed this way from the beginning. The problem with what you think should happen is that it gives the user a misleading information, and iirc that was the reason why didn't do this - because the user thinks he's XA while he is really not. Therefore we said to always unite the presences at the "most online" one. I agree this is not really good solution and I'm happy rethinking it. What we could possibly do is always show requested presence but put an overlay on top of the presence icon if not all of the accounts are on that presence, so the user is actually aware of the fact that not all accounts are on that presence. Details are then displayed in the tooltip (means extending presence plasmoid tooltip).
>I remember it was designed this way from the beginning. Quite possibly. I recall discussing it too. >means extending presence plasmoid tooltip +++ I don't think extending this "bodge" to be more global is the correct solution. Especially as I think it's possible to deadlock this if you had two accounts that. I say we leave this as unconfirmed, and work towards fixing the root issue. http://community.kde.org/KTp/Tasks/NonGlobalPresence
This is odd. I just had a review request to change it from currentPresence to globalPresence. I'm very confused now. Surely that means the bug was invalid until now, and only now makes sense. (though I think I still disagree with it)
See my last comment. Closing.