Rather long email, sorry. Thanks for working on this kded stuff.
There's a reason we don't use setGlobalPresence at the moment. It was decided that we should never try to bring an offline account online. Otherwise we run into problems where you have an account that can't connect (bad password or something) then go auto away and back - suddenly you get new popups. FYI, on the second patch you don't need to disconnect a signal when an account is removed - it will happen automatically. Am I right in thinking your patch (http://paste.kde.org/p15ed68b8/) means we should undo https://git.reviewboard.kde.org/r/112442/ and https://git.reviewboard.kde.org/r/112524/ ? from your original bug In your sequence: The event sequence: 1. Autoaway activate 2. Auto suspend 3. Resume 4. No network 5. autoaway deactivate 6. Wifi connected 7. Presence back to the one when network disconnected, which is away. So why does it go to "away" at 7? What is actually happening 4. No network 5. autoaway deactivate However due to the line you've just shown me, this does nothing - we look at setting the presence to the last user set presence.. but because our account is offline we do nothing. This (I think) is the cause of our problem. When MC restores at 7 it has no idea we've changed something. with your patch that problem goes away. Maybe we could change it to: - if (account->isEnabled() && account->isOnline()) { setRequestedPresence(presence); } to (if account->isenabled && (account->account->connectionStatusReason == ReasonNone || account->connectionStatusReason == RequestedRequested) { setRequestedPresence(presence); that should work at (5) if the account was online before and was brought down deliberately, but not have the problems we had that caused us to add that condition. -------------------------------------------------- Long term. One thing that's really difficult in this whole codebase is trying to identify user set presences vs auto away vs network up/down. One idea I've had is to try and move the auto away code into mission-control, it has a plugin system we could add a new dbus interface to tell MC when we're in away - and it can do all the work. The other idea I've been thinking about is abusing the automaticPresence enum to keep a difference between user set presences and computer set presences. If anything manual (contact list + presence plasmoid) always set the automaticPresence as well as the requestedPresence. our sequence then could then be onAutoAway() { account->requestPresence(away); } onEndAutoAway() { account->requestPresence(account->automaticPresence); } (but with the whole plugin stack system) it would be simpler than all our current mess comparing presences with what the plugin system thinks it should be. No idea if it would work. _______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
