(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.

(In reply to comment #1)
> With that API, Shell would set the presence type to Available on sign-in

Actually, I'd be tempted to say Shell should set RequestedPresence := AutomaticPresence on each account (perhaps with a MC API shortcut to do that). Or perhaps accounts should "normally" be created with CreateAutomatically=TRUE (Bug #29021) and MC should apply that logic iff at least one client is controlling IM status (Bug #40132)...

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/141.