Tp::Client::ConnectionInterfaceContactListInterface Class Reference [Connection proxies]

#include <TelepathyQt4/Connection>

Inherits Tp::AbstractInterface.

List of all members.

Public Slots

• QDBusPendingReply
  < Tp::ContactAttributesMap > GetContactListAttributes (const QStringList &interfaces, bool hold)
• QDBusPendingReply RequestSubscription (const Tp::UIntList &contacts, const QString &message)
• QDBusPendingReply AuthorizePublication (const Tp::UIntList &contacts)
• QDBusPendingReply RemoveContacts (const Tp::UIntList &contacts)
• QDBusPendingReply Unsubscribe (const Tp::UIntList &contacts)
• QDBusPendingReply Unpublish (const Tp::UIntList &contacts)

Signals

• void ContactListStateChanged (uint contactListState)
• void ContactsChanged (const Tp::ContactSubscriptionMap &changes, const Tp::UIntList &removals)

Public Member Functions

• ConnectionInterfaceContactListInterface (const QString &busName, const QString &objectPath, QObject *parent=0)
• ConnectionInterfaceContactListInterface (const QDBusConnection &connection, const QString &busName, const QString &objectPath, QObject *parent=0)
• ConnectionInterfaceContactListInterface (Tp::DBusProxy *proxy)
• ConnectionInterfaceContactListInterface (const Tp::Client::ConnectionInterface &mainInterface)
• ConnectionInterfaceContactListInterface (const Tp::Client::ConnectionInterface &mainInterface, QObject *parent)
• TELEPATHY_QT4_DEPRECATED uint ContactListState () const
• Tp::PendingVariant * requestPropertyContactListState () const
• TELEPATHY_QT4_DEPRECATED bool ContactListPersists () const
• Tp::PendingVariant * requestPropertyContactListPersists () const
• TELEPATHY_QT4_DEPRECATED bool CanChangeContactList () const
• Tp::PendingVariant * requestPropertyCanChangeContactList () const
• TELEPATHY_QT4_DEPRECATED bool RequestUsesMessage () const
• Tp::PendingVariant * requestPropertyRequestUsesMessage () const
• Tp::PendingVariantMap * requestAllProperties () const

Static Public Member Functions

• static const char * staticInterfaceName ()

Protected Member Functions

• virtual void invalidate (Tp::DBusProxy *, const QString &, const QString &)

Properties

• uint ContactListState
• bool ContactListPersists
• bool CanChangeContactList
• bool RequestUsesMessage

---

Detailed Description

Proxy class providing a 1:1 mapping of the D-Bus interface "org.freedesktop.Telepathy.Connection.Interface.ContactList."

---

Constructor & Destructor Documentation

Tp::Client::ConnectionInterfaceContactListInterface::ConnectionInterfaceContactListInterface	(	const QString &	busName,
		const QString &	objectPath,
		QObject *	parent = 0
	)

Creates a ConnectionInterfaceContactListInterface associated with the given object on the session bus.

Parameters:

	busName	Name of the service the object is on.
	objectPath	Path to the object on the service.
	parent	Passed to the parent class constructor.

Tp::Client::ConnectionInterfaceContactListInterface::ConnectionInterfaceContactListInterface	(	const QDBusConnection &	connection,
		const QString &	busName,
		const QString &	objectPath,
		QObject *	parent = 0
	)

Creates a ConnectionInterfaceContactListInterface associated with the given object on the given bus.

Parameters:

	connection	The bus via which the object can be reached.
	busName	Name of the service the object is on.
	objectPath	Path to the object on the service.
	parent	Passed to the parent class constructor.

Tp::Client::ConnectionInterfaceContactListInterface::ConnectionInterfaceContactListInterface

(

Tp::DBusProxy *

proxy

)

Creates a ConnectionInterfaceContactListInterface associated with the same object as the given proxy.

Parameters:

proxy

The proxy to use. It will also be the QObject::parent() for this object.

Tp::Client::ConnectionInterfaceContactListInterface::ConnectionInterfaceContactListInterface

(

const Tp::Client::ConnectionInterface &

mainInterface

)

[explicit]

Creates a ConnectionInterfaceContactListInterface associated with the same object as the given proxy. Additionally, the created proxy will have the same parent as the given proxy.

Parameters:

mainInterface

The proxy to use.

Tp::Client::ConnectionInterfaceContactListInterface::ConnectionInterfaceContactListInterface	(	const Tp::Client::ConnectionInterface &	mainInterface,
		QObject *	parent
	)

Creates a ConnectionInterfaceContactListInterface associated with the same object as the given proxy. However, a different parent object can be specified.

Parameters:

	mainInterface	The proxy to use.
	parent	Passed to the parent class constructor.

---

Member Function Documentation

static const char* Tp::Client::ConnectionInterfaceContactListInterface::staticInterfaceName

(

)

[inline, static]

Returns the name of the interface "org.freedesktop.Telepathy.Connection.Interface.ContactList", which this class represents.

Returns:

The D-Bus interface name.

TELEPATHY_QT4_DEPRECATED uint Tp::Client::ConnectionInterfaceContactListInterface::ContactListState

(

)

const [inline]

Getter for the remote object property "ContactListState".

Don't use this: it blocks the main loop. Use the asynchronous requestPropertyContactListState() instead.

Returns:

The value of the property, or a default-constructed value if the property is not readable.

Tp::PendingVariant* Tp::Client::ConnectionInterfaceContactListInterface::requestPropertyContactListState

(

)

const [inline]

Asynchronous getter for the remote object property "ContactListState" of type uint.

The progress made in retrieving the contact list. Change notification is via ContactListStateChanged.

Returns:

A pending variant which will emit finished when the property has been retrieved.

TELEPATHY_QT4_DEPRECATED bool Tp::Client::ConnectionInterfaceContactListInterface::ContactListPersists

(

)

const [inline]

Getter for the remote object property "ContactListPersists".

Don't use this: it blocks the main loop. Use the asynchronous requestPropertyContactListPersists() instead.

Returns:

The value of the property, or a default-constructed value if the property is not readable.

Tp::PendingVariant* Tp::Client::ConnectionInterfaceContactListInterface::requestPropertyContactListPersists

(

)

const [inline]

Asynchronous getter for the remote object property "ContactListPersists" of type bool.

If true, presence subscriptions (in both directions) on this connection are stored by the server or other infrastructure.

<tp:rationale>

XMPP, MSN, ICQ, etc. all behave like this. </tp:rationale>

If false, presence subscriptions on this connection are not stored.

<tp:rationale>

In SIMPLE (SIP), clients are expected to keep a record of subscriptions, as described below. In link-local XMPP, subscriptions are implicit (everyone on the local network receives presence from everyone else) so nothing is ever stored. </tp:rationale>

If <tp:member-ref>CanChangeContactList</tp:member-ref> is true, Telepathy clients (e.g. user interfaces or address books) MAY keep a record of permission to publish and requests to subscribe locally, and attempt to restore it for each Connection. If ContactListPersists is false, clients MAY do this for all contacts; if ContactListPersists is true, clients SHOULD NOT change the state of contacts that were not changed locally.

<tp:rationale>

In SIMPLE (SIP), ContactListPersists is false, but CanChangeContactList is true. Presence will not be received unless clients renew any subscriptions they have for each connection, in the way described. There is no server-side storage, so clients have no alternative but to maintain independent contact lists.

In protocols like XMPP and MSN, it may be useful for clients to queue up subscription requests or removals made while offline and process them next time the connection is online. However, clients should only replay the changes, rather than resetting the contact list to match a stored copy, to avoid overwriting changes that were made on the server. </tp:rationale>

Clients that replay requests like this SHOULD do so by calling AuthorizePublication to pre-approve publication of presence to the appropriate contacts, followed by RequestSubscription to request the appropriate contacts' presences.

This property cannot change after the connection has moved to the Connected state. Until then, its value is undefined, and it may change at any time, without notification.

Returns:

A pending variant which will emit finished when the property has been retrieved.

TELEPATHY_QT4_DEPRECATED bool Tp::Client::ConnectionInterfaceContactListInterface::CanChangeContactList

(

)

const [inline]

Getter for the remote object property "CanChangeContactList".

Don't use this: it blocks the main loop. Use the asynchronous requestPropertyCanChangeContactList() instead.

Returns:

The value of the property, or a default-constructed value if the property is not readable.

Tp::PendingVariant* Tp::Client::ConnectionInterfaceContactListInterface::requestPropertyCanChangeContactList

(

)

const [inline]

Asynchronous getter for the remote object property "CanChangeContactList" of type bool.

If true, presence subscription and publication can be changed using the <tp:member-ref>RequestSubscription</tp:member-ref>, <tp:member-ref>AuthorizePublication</tp:member-ref> and <tp:member-ref>RemoveContacts</tp:member-ref> methods.

If false, all of those methods will always fail; they SHOULD raise the error org.freedesktop.Telepathy.Error.NotImplemented.

<tp:rationale>

In XEP-0174 "Serverless Messaging" (link-local XMPP), presence is implicitly published to everyone in the local subnet, so the user cannot control their presence publication. </tp:rationale>

This property cannot change after the connection has moved to the Connected state. Until then, its value is undefined, and it may change at any time, without notification.

Returns:

A pending variant which will emit finished when the property has been retrieved.

TELEPATHY_QT4_DEPRECATED bool Tp::Client::ConnectionInterfaceContactListInterface::RequestUsesMessage

(

)

const [inline]

Getter for the remote object property "RequestUsesMessage".

Don't use this: it blocks the main loop. Use the asynchronous requestPropertyRequestUsesMessage() instead.

Returns:

The value of the property, or a default-constructed value if the property is not readable.

Tp::PendingVariant* Tp::Client::ConnectionInterfaceContactListInterface::requestPropertyRequestUsesMessage

(

)

const [inline]

Asynchronous getter for the remote object property "RequestUsesMessage" of type bool.

If true, the Message parameter to <tp:member-ref>RequestSubscription</tp:member-ref> is likely to be significant, and user interfaces SHOULD prompt the user for a message to send with the request; a message such as "I would like to add you to my contact list", translated into the local user's language, might make a suitable default.

<tp:rationale>

This matches user expectations in XMPP and ICQ, for instance. </tp:rationale>

If false, the parameter is ignored; user interfaces SHOULD avoid prompting the user, and SHOULD pass an empty string to RequestSubscription.

<tp:rationale>

FIXME: is there any such protocol? </tp:rationale>

Returns:

A pending variant which will emit finished when the property has been retrieved.

Tp::PendingVariantMap* Tp::Client::ConnectionInterfaceContactListInterface::requestAllProperties

(

)

const [inline]

Request all of the DBus properties on the interface.

Returns:

A pending variant map which will emit finished when the properties have been retrieved.

QDBusPendingReply<Tp::ContactAttributesMap> Tp::Client::ConnectionInterfaceContactListInterface::GetContactListAttributes	(	const QStringList &	interfaces,
		bool	hold
	)			[inline, slot]

Begins a call to the D-Bus method "GetContactListAttributes" on the remote object.

Return some contact attributes for a list of contacts associated with the user. This list MUST include at least:

• all contacts whose <tp:token-ref>subscribe</tp:token-ref> attribute is not No
• all contacts whose <tp:token-ref>publish</tp:token-ref> attribute is not No

but MAY contain other contacts.

<tp:rationale>

For instance, on XMPP, all contacts on the roster would appear here even if they have subscription="none", unless there's reason to believe the user does not want to see them (such as having been blocked). </tp:rationale>

This list does not need to contain every visible contact: for instance, contacts seen in XMPP or IRC chatrooms SHOULD NOT appear here. Blocked contacts SHOULD NOT appear here, unless they still have a non-No <tp:token-ref>subscribe</tp:token-ref> or <tp:token-ref>publish</tp:token-ref> attribute for some reason.

<tp:rationale>

It's reasonable to assume that blocked contacts should not be visible to the user unless they specifically go looking for them, at least in protocols like XMPP where blocking a contact suppresses presence. </tp:rationale>

Parameters:

interfaces

A list of strings indicating which D-Bus interfaces the calling process is interested in. Equivalent to the corresponding argument to <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Contacts">GetContactAttributes</tp:dbus-ref>, except that if this list does not contain the ContactList interface itself, it is treated as though that interface was also requested.

Parameters:

hold

Whether to hold the handles on behalf of the calling process. Equivalent to the corresponding argument to <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Contacts">GetContactAttributes</tp:dbus-ref>.

Returns:

A dictionary mapping the contact handles to contact attributes, equivalent to the result of <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Contacts">GetContactAttributes</tp:dbus-ref>.

QDBusPendingReply Tp::Client::ConnectionInterfaceContactListInterface::RequestSubscription	(	const Tp::UIntList &	contacts,
		const QString &	message
	)			[inline, slot]

Begins a call to the D-Bus method "RequestSubscription" on the remote object.

Request that the given contacts allow the local user to subscribe to their presence, i.e. that their subscribe attribute becomes Yes.

Before calling this method on a connection where <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Aliasing">GetAliasFlags</tp:dbus-ref> returns the User_Set flag, user interfaces SHOULD obtain, from the user, an alias to identify the contact in future, and store it using <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Aliasing">SetAliases</tp:dbus-ref>.

The user MAY be prompted using the contact's current self-assigned nickname, or something derived from the contact's (presumably self-assigned) identifier, as a default, but these names chosen by the contact SHOULD NOT be used without user approval.

<tp:rationale>

This is a generalization of XEP-0165 "Best Practices to Discourage JID Mimicking") to protocols other than XMPP. A reasonable user interface for this, as used in many XMPP clients, is to have a text entry for the alias adjacent to the text entry for the identifier to add. </tp:rationale>

For contacts with subscribe=Yes, this method has no effect. It MUST return successfully if all contacts are in this state.

For contacts with subscribe=Ask, this method SHOULD send a new request, with the given message, if allowed by the underlying protocol.

For contacts with subscribe=No or subscribe=Rejected, this method SHOULD request that the contact allows the local user to subscribe to their presence; in general, this will change their publish attribute to Ask (although it could change directly to Yes in some situations).

Any state changes that immediately result from this request MUST be signalled via <tp:member-ref>ContactsChanged</tp:member-ref> before this method returns.

<tp:rationale>

This makes it easy for user interfaces to see what practical effect this method had. </tp:rationale>

If the remote contact accepts the request, their subscribe attribute will later change from Ask to Yes.

If the remote contact explicitly rejects the request (in protocols that allow this), their subscribe attribute will later change from Ask to Rejected.

If the subscription request is cancelled by the local user, the contact's subscribe attribute will change from Ask to No.

This method SHOULD NOT be called until the <tp:member-ref>ContactListState</tp:member-ref> changes to Success. If the <tp:member-ref>ContactListState</tp:member-ref> changes to Failure, this method SHOULD raise the same error as <tp:member-ref>GetContactListAttributes</tp:member-ref>.

Parameters:

contacts

One or more contacts to whom requests are to be sent.

Parameters:

message

An optional plain-text message from the user, to send to those contacts with the subscription request. The <tp:member-ref>RequestUsesMessage</tp:member-ref> property indicates whether this message will be used or ignored.

Clients SHOULD NOT send a non-empty message without first giving the user an opportunity to edit it.

<tp:rationale>

These messages are typically presented to the remote contact as if the user had typed them, so as a minimum, the user should be allowed to see what the UI will be saying on their behalf. </tp:rationale>

Connections where this message is not useful MUST still allow it to be non-empty.

QDBusPendingReply Tp::Client::ConnectionInterfaceContactListInterface::AuthorizePublication

(

const Tp::UIntList &

contacts

)

[inline, slot]

Begins a call to the D-Bus method "AuthorizePublication" on the remote object.

For each of the given contacts, request that the local user's presence is sent to that contact, i.e. that their publish attribute becomes Yes.

For contacts with publish=Yes, this method has no effect; it MUST return successfully if all contacts given have this state.

For contacts with publish=Ask, this method accepts the contact's request to see the local user's presence, changing their publish attribute from Ask to Yes.

For contacts with publish=No, if the protocol allows it, this method allows the contacts to see the local user's presence even though they have not requested it, changing their publish attribute from No to Yes. Otherwise, it merely records the fact that presence publication to those contacts is allowed; if any of those contacts ask to receive the local user's presence later in the lifetime of the connection, the connection SHOULD immediately allow them to do so, changing their publish attribute directly from No to Yes.

<tp:rationale>

This makes it easy to implement the common UI policy that if the user attempts to subscribe to a contact's presence, requests for reciprocal subscription are automatically approved. </tp:rationale>

Any state changes that immediately result from this request MUST be signalled via <tp:member-ref>ContactsChanged</tp:member-ref> before this method returns.

<tp:rationale>

This makes it easy for user interfaces to see what practical effect this method had. </tp:rationale>

This method SHOULD NOT be called until the <tp:member-ref>ContactListState</tp:member-ref> changes to Success. If the <tp:member-ref>ContactListState</tp:member-ref> changes to Failure, this method SHOULD raise the same error as <tp:member-ref>GetContactListAttributes</tp:member-ref>.

Parameters:

contacts

One or more contacts to authorize.

QDBusPendingReply Tp::Client::ConnectionInterfaceContactListInterface::RemoveContacts

(

const Tp::UIntList &

contacts

)

[inline, slot]

Begins a call to the D-Bus method "RemoveContacts" on the remote object.

Remove the given contacts from the contact list entirely. It is protocol-dependent whether this works, and under which circumstances.

If possible, this method SHOULD set the contacts' subscribe and publish attributes to No, remove any stored aliases for those contacts, and remove the contacts from the result of <tp:member-ref>GetContactListAttributes</tp:member-ref>.

This method SHOULD succeed even if it was not possible to carry out the request entirely or for all contacts (for instance, if there is an outstanding request to subscribe to the contact's presence, and it's not possible to cancel such requests). However, all signals that immediately result from this method call MUST be emitted before it returns, so that clients can interpret the result.

<tp:rationale>

User interfaces removing a contact from the contact list are unlikely to want spurious failure notifications resulting from limitations of a particular protocol. However, emitting the signals first means that if a client does want to check exactly what happened, it can wait for the method to return (while applying change-notification signals to its local cache of the contact list's state), then consult its local cache of the contact list's state to see whether the contact is still there. </tp:rationale>

This method SHOULD NOT be called until the <tp:member-ref>ContactListState</tp:member-ref> changes to Success. If the <tp:member-ref>ContactListState</tp:member-ref> changes to Failure, this method SHOULD raise the same error as <tp:member-ref>GetContactListAttributes</tp:member-ref>.

Parameters:

contacts

One or more contacts to remove.

QDBusPendingReply Tp::Client::ConnectionInterfaceContactListInterface::Unsubscribe

(

const Tp::UIntList &

contacts

)

[inline, slot]

Begins a call to the D-Bus method "Unsubscribe" on the remote object.

Attempt to set the given contacts' subscribe attribute to No, i.e. stop receiving their presence.

For contacts with subscribe=Ask, this attempts to cancel an earlier request to subscribe to the contact's presence; for contacts with subscribe=Yes, this attempts to unsubscribe from the contact's presence.

As with <tp:member-ref>RemoveContacts</tp:member-ref>, this method SHOULD succeed even if it was not possible to carry out the request entirely or for all contacts; however, all signals that immediately result from this method call MUST be emitted before it returns.

This method SHOULD NOT be called until the <tp:member-ref>ContactListState</tp:member-ref> changes to Success. If the <tp:member-ref>ContactListState</tp:member-ref> changes to Failure, this method SHOULD raise the same error as <tp:member-ref>GetContactListAttributes</tp:member-ref>.

Parameters:

contacts

One or more contacts to remove.

QDBusPendingReply Tp::Client::ConnectionInterfaceContactListInterface::Unpublish

(

const Tp::UIntList &

contacts

)

[inline, slot]

Begins a call to the D-Bus method "Unpublish" on the remote object.

Attempt to set the given contacts' publish attribute to No, i.e. stop sending presence to them.

For contacts with publish=Ask, this method explicitly rejects the contact's request to subscribe to the user's presence; for contacts with publish=Yes, this method attempts to prevent the user's presence from being received by the contact.

As with <tp:member-ref>RemoveContacts</tp:member-ref>, this method SHOULD succeed even if it was not possible to carry out the request entirely or for all contacts; however, all signals that immediately result from this method call MUST be emitted before it returns.

This method SHOULD NOT be called until the <tp:member-ref>ContactListState</tp:member-ref> changes to Success. If the <tp:member-ref>ContactListState</tp:member-ref> changes to Failure, this method SHOULD raise the same error as <tp:member-ref>GetContactListAttributes</tp:member-ref>.

Parameters:

contacts

One or more contacts to remove.

void Tp::Client::ConnectionInterfaceContactListInterface::ContactListStateChanged

(

uint

contactListState

)

[signal]

Represents the signal "ContactListStateChanged" on the remote object.

Emitted when ContactListState changes.

Parameters:

contactListState

The new value of ContactListState.

void Tp::Client::ConnectionInterfaceContactListInterface::ContactsChanged	(	const Tp::ContactSubscriptionMap &	changes,
		const Tp::UIntList &	removals
	)			[signal]

Represents the signal "ContactsChanged" on the remote object.

Emitted when the contact list becomes available, when contacts' basic stored properties change, when new contacts are added to the list that would be returned by <tp:member-ref>GetContactListAttributes</tp:member-ref>, or when contacts are removed from that list.

<tp:rationale>

This provides change notification for that list, and for contacts' <tp:token-ref>subscribe</tp:token-ref>, <tp:token-ref>publish</tp:token-ref> and <tp:token-ref>publish-request</tp:token-ref> attributes. </tp:rationale>

Connection managers SHOULD also emit this signal when a contact requests that the user's presence is published to them, even if that contact's <tp:token>publish</tp:token> attribute is already Ask and the <tp:token>publish-request</tp:token> has not changed.

<tp:rationale>

If the same contact sends 10 identical requests, 10 identical signals should be emitted. </tp:rationale>

Parameters:

	changes	The new subscribe, publish and publish-request attributes of all the contacts that have been added, and all the contacts for which those attributes have changed.
	removals	The contacts that have been removed from the list that would be returned by GetContactListAttributes. This also implies that they have subscribe = No and publish = No; contacts MUST NOT be listed both here and in Changes.

void Tp::Client::ConnectionInterfaceContactListInterface::invalidate	(	Tp::DBusProxy *	proxy,
		const QString &	error,
		const QString &	message
	)			[protected, virtual]

Reimplemented from Tp::AbstractInterface.

---

Property Documentation

uint Tp::Client::ConnectionInterfaceContactListInterface::ContactListState [read]

Represents property "ContactListState" on the remote object.

The progress made in retrieving the contact list. Change notification is via ContactListStateChanged.

bool Tp::Client::ConnectionInterfaceContactListInterface::ContactListPersists [read]

Represents property "ContactListPersists" on the remote object.

If true, presence subscriptions (in both directions) on this connection are stored by the server or other infrastructure.

<tp:rationale>

XMPP, MSN, ICQ, etc. all behave like this. </tp:rationale>

If false, presence subscriptions on this connection are not stored.

<tp:rationale>

In SIMPLE (SIP), clients are expected to keep a record of subscriptions, as described below. In link-local XMPP, subscriptions are implicit (everyone on the local network receives presence from everyone else) so nothing is ever stored. </tp:rationale>

If <tp:member-ref>CanChangeContactList</tp:member-ref> is true, Telepathy clients (e.g. user interfaces or address books) MAY keep a record of permission to publish and requests to subscribe locally, and attempt to restore it for each Connection. If ContactListPersists is false, clients MAY do this for all contacts; if ContactListPersists is true, clients SHOULD NOT change the state of contacts that were not changed locally.

<tp:rationale>

In SIMPLE (SIP), ContactListPersists is false, but CanChangeContactList is true. Presence will not be received unless clients renew any subscriptions they have for each connection, in the way described. There is no server-side storage, so clients have no alternative but to maintain independent contact lists.

In protocols like XMPP and MSN, it may be useful for clients to queue up subscription requests or removals made while offline and process them next time the connection is online. However, clients should only replay the changes, rather than resetting the contact list to match a stored copy, to avoid overwriting changes that were made on the server. </tp:rationale>

Clients that replay requests like this SHOULD do so by calling AuthorizePublication to pre-approve publication of presence to the appropriate contacts, followed by RequestSubscription to request the appropriate contacts' presences.

This property cannot change after the connection has moved to the Connected state. Until then, its value is undefined, and it may change at any time, without notification.

bool Tp::Client::ConnectionInterfaceContactListInterface::CanChangeContactList [read]

Represents property "CanChangeContactList" on the remote object.

If true, presence subscription and publication can be changed using the <tp:member-ref>RequestSubscription</tp:member-ref>, <tp:member-ref>AuthorizePublication</tp:member-ref> and <tp:member-ref>RemoveContacts</tp:member-ref> methods.

If false, all of those methods will always fail; they SHOULD raise the error org.freedesktop.Telepathy.Error.NotImplemented.

<tp:rationale>

In XEP-0174 "Serverless Messaging" (link-local XMPP), presence is implicitly published to everyone in the local subnet, so the user cannot control their presence publication. </tp:rationale>

This property cannot change after the connection has moved to the Connected state. Until then, its value is undefined, and it may change at any time, without notification.

bool Tp::Client::ConnectionInterfaceContactListInterface::RequestUsesMessage [read]

Represents property "RequestUsesMessage" on the remote object.

If true, the Message parameter to <tp:member-ref>RequestSubscription</tp:member-ref> is likely to be significant, and user interfaces SHOULD prompt the user for a message to send with the request; a message such as "I would like to add you to my contact list", translated into the local user's language, might make a suitable default.

<tp:rationale>

This matches user expectations in XMPP and ICQ, for instance. </tp:rationale>

If false, the parameter is ignored; user interfaces SHOULD avoid prompting the user, and SHOULD pass an empty string to RequestSubscription.

<tp:rationale>

FIXME: is there any such protocol? </tp:rationale>