Methods
| CreateAccount | (s: Connection_Manager, s: Protocol, s: Display_Name, a{sv}: Parameters, a{sv}: Properties) | → | o: Account |
Signals
| AccountRemoved | (o: Account) | |
| AccountValidityChanged | (o: Account, b: Valid) |
Properties
| Interfaces | as (DBus_Interface_List) | Read only | |
| ValidAccounts | ao | Read only | |
| InvalidAccounts | ao | Read only | |
| SupportedAccountProperties | as (DBus_Qualified_Member_List) | Read only |
Description
The account manager is a central service used to store account details.
The current account manager is defined to be the process that owns the well-known bus name org.freedesktop.Telepathy.AccountManager on the session bus. This process must export an /org/freedesktop/Telepathy/AccountManager object with the AccountManager interface.
Until a mechanism exists for making a reasonable automatic choice of AccountManager implementation, implementations SHOULD NOT register as an activatable service for the AccountManager's well-known bus name. Instead, it is RECOMMENDED that some component of the user's session will select and activate a particular implementation, and that other Telepathy-enabled programs can detect whether Telepathy is in use by checking whether the AccountManager's well-known name is in use at runtime.
Methods
CreateAccount (s: Connection_Manager, s: Protocol, s: Display_Name, a{sv}: Parameters, a{sv}: Properties) → o: Account
Parameters
- Connection_Manager — s (Connection_Manager_Name)
- Protocol — s (Protocol)
- Display_Name — s
- Parameters — a{sv}
- Properties — a{sv} (Qualified_Property_Value_Map)
The account creation UI may ask the user for a name for the new account. If the author of the UI chooses not to do this, the account creation UI is better able to suggest a default display name because it has protocol-specific knowledge which the account manager does not.
The account manager always knows the complete list of accounts so it can easily tell whether it should append something to the display name to avoid presenting two identically-named accounts to the user.
The values of any other properties to be set immediately on the new Account.
Only the properties mentioned in SupportedAccountProperties are acceptable here. In particular, the DisplayName and Parameters properties are never allowed here, since they are set using the other arguments to this method.
Account manager implementations SHOULD support creating accounts with an empty value for this argument.
Returns
- Account — o
Possible Errors
- Not Implemented
- Invalid Argument
The Connection_Manager is not installed or does not implement the given Protocol, or one of the properties in the Properties argument is unsupported.
The Parameters provided omit a required parameter or provide unsupported parameter, or the type of one of the Parameters or Properties is inappropriate.
Signals
AccountRemoved (o: Account)
Parameters
- Account — o
AccountValidityChanged (o: Account, b: Valid)
Parameters
- Account — o
- Valid — b
Properties
Interfaces — as (DBus_Interface_List)
ValidAccounts — ao
InvalidAccounts — ao
SupportedAccountProperties — as (DBus_Qualified_Member_List)
A list of the fully qualified names of properties that can be set via the Properties argument to CreateAccount when an account is created.
Examples of good properties to support here include Icon, Enabled, Nickname, AutomaticPresence, ConnectAutomatically, RequestedPresence and Avatar.
Examples of properties that would make no sense here include Valid, Connection, ConnectionStatus, ConnectionStatusReason, CurrentPresence and NormalizedName.
This property MUST NOT include include the DisplayName and Parameters properties, which are set using separate arguments.
This property MAY include the names of properties that, after account creation, will be read-only: this indicates that the property can be set at account creation but not changed later.
For example, an account manager might support migration tools that use this to preserve the HasBeenOnline property, even though that property is usually read-only.