Need some help for final fix to the presence not restored

[David Edmundson]

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.