[Bug 70427] Account: add 'OnlyUsedByClient' property?

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=70427

--- Comment #1 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #0)
> We'd like to have Polari behaving like a 'normal' IRC client (like XChat).
> That means that IRC accounts are connected when Polari is started and
> disconnected when it's exited.

MC has quite a lot of features. Which ones do these accounts (not) want?

Devil's advocate: what's the advantage in having these accounts exist in MC at
all? Should they just be "behind MC's back", with some mechanism for flagging
them as "hey MC, please ignore this connection"?

(A reasonable response to that would be "we want MC features X, Y and Z to
apply to these accounts, but not features A, B or C".)

Are the GNOME designers convinced that Polari should handle every feature of
IRC, including private messages, and this decision will never change? I would
have expected that PRIVMSG would be in Empathy or Chat.

Are the GNOME designers convinced that Polari will only ever handle IRC, and
will not be used for XMPP rooms? (That seems like a backward step to me, but,
whatever; it's their design.)

> Let's say an Account 'A' has C has Account.OnlyUsedByClient value:
> - C is responsible of handling A's presence/connection status. Especially,
> changing our global presence in Empathy or Shell shouldn't affect A.

MC has no concept of global presence; presence is per-account. telepathy-glib
would need to be modified to skip OnlyUsedByClient accounts, unless we
implement Bug #24104, for which I had some ideas 3 years ago that never got
feedback.

> - All channels from A should be handled by C. See also bug #30963 for
> another attempt to solve this issue. This should prevent the kind of problem
> I described in https://bugzilla.gnome.org/show_bug.cgi?id=599184#c29
> - Accounts UI like empathy-chat may or may not display A. Actually this may
> be a replacement for the Hidden API (bug #33101)?

It seems broadly similar, with the exception that Hidden performed normal
dispatching (I think), so Ytstenut clients could register themselves as the
Handler for particular types of tube channels (I think).

> We should probably have API to enfore accounts change even for those
> accounts. For example, we probably still want to change their presence to
> away when the computer is idle. (Or maybe this should be done directly by MC
> itself?)

I'm in two minds about auto-idle. It's essentially a UI policy thing, but at
the same time, MC is much, much better at "remember old presence and go back to
it" than Shell is.

Possibly something like this?

    AM.I.Idling (or AM core)
        AutoAway : rw u
            The maximum possible presence type across all accounts.
            Must be an online presence type (Available, Busy, Away,
            Extended_Away or Hidden[1]). The initial value on AM
            startup is Available.

            If changed from Available to non-Available,
            the AM remembers the current presence of each account[2],
            then for each account whose RequestedPresence[3] is currently
            "more available" than AutoAway, changes that account's
            RequestedPresence to (AutoAway, '', '').

            If an account's RequestedPresence is changed by a client
            while in this "auto-away" state, it modifies both
            RequestedPresence and the remembered presence. The account's
            RequestedPresence may still be changed to "less available"
            by a subsequent change to the value of AutoAway.

            If changed from non-Available to Available,
            the AM sets the RequestedPresence of each account to the
            value it remembered.

With that API, Shell would set the presence type to Available on sign-in, but
from then on it would only modify AutoAway. A UI for control freaks (Empathy)
would still manipulate the presence of all accounts (?).

[1] Does Hidden make sense here?
[2] Should it go in a new read-only property, so we can refer to it more easily
and clients can query it?
[3] Should this algorithm check CurrentPresence?

Alternatively, we could redefine RequestedPresence so that the presence that is
actually requested is min(AutoAway, RequestedPresence) - but that seems pretty
weird, and there'd be no property for what MC actually asked the CM for (!)
unless we explicitly added one.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.