Home · All Classes · All Namespaces · Modules · Functions · Files
Public Slots | Public Member Functions | Static Public Member Functions | Protected Member Functions | Properties

Tp::Client::ClientHandlerInterface Class Reference
[Client proxies]

#include <TelepathyQt4/Client>

Inherits Tp::AbstractInterface.

List of all members.

Public Slots

Public Member Functions

Static Public Member Functions

Protected Member Functions

Properties


Detailed Description

Proxy class providing a 1:1 mapping of the D-Bus interface "org.freedesktop.Telepathy.Client.Handler."


Constructor & Destructor Documentation

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

Creates a ClientHandlerInterface 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::ClientHandlerInterface::ClientHandlerInterface ( const QDBusConnection &  connection,
const QString &  busName,
const QString &  objectPath,
QObject *  parent = 0 
)

Creates a ClientHandlerInterface 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::ClientHandlerInterface::ClientHandlerInterface ( Tp::DBusProxy proxy  ) 

Creates a ClientHandlerInterface 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::ClientHandlerInterface::ClientHandlerInterface ( const Tp::Client::ClientInterface mainInterface  )  [explicit]

Creates a ClientHandlerInterface 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::ClientHandlerInterface::ClientHandlerInterface ( const Tp::Client::ClientInterface mainInterface,
QObject *  parent 
)

Creates a ClientHandlerInterface 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::ClientHandlerInterface::staticInterfaceName (  )  [inline, static]

Returns the name of the interface "org.freedesktop.Telepathy.Client.Handler", which this class represents.

Returns:
The D-Bus interface name.
TELEPATHY_QT4_DEPRECATED Tp::ChannelClassList Tp::Client::ClientHandlerInterface::HandlerChannelFilter (  )  const [inline]

Getter for the remote object property "HandlerChannelFilter".

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

Returns:
The value of the property, or a default-constructed value if the property is not readable.
Tp::PendingVariant* Tp::Client::ClientHandlerInterface::requestPropertyHandlerChannelFilter (  )  const [inline]

Asynchronous getter for the remote object property "HandlerChannelFilter" of type Tp::ChannelClassList.

A specification of the channels that this channel handler can deal with. It will be offered to approvers as a potential channel handler for bundles that contain only suitable channels, or for suitable channels that must be handled separately.

This property works in exactly the same way as the <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Observer.ObserverChannelFilter</tp:dbus-ref> property. In particular, it cannot change while the handler process continues to own the corresponding Client bus name.

In the .client file, it is represented in the same way as ObserverChannelFilter, but the group has the same name as this interface and the keys start with HandlerChannelFilter instead of ObserverChannelFilter.

Returns:
A pending variant which will emit finished when the property has been retrieved.
TELEPATHY_QT4_DEPRECATED bool Tp::Client::ClientHandlerInterface::BypassApproval (  )  const [inline]

Getter for the remote object property "BypassApproval".

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

Returns:
The value of the property, or a default-constructed value if the property is not readable.
Tp::PendingVariant* Tp::Client::ClientHandlerInterface::requestPropertyBypassApproval (  )  const [inline]

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

If true, channels destined for this handler are automatically handled, without invoking approvers.

<tp:rationale>

The intended usage is to allow a client handling one channel to pick up closely related channels. Suppose a client capable of handling both Text and StreamedMedia, org.freedesktop.Telepathy.Client.Empathy, is handling a StreamedMedia channel. That client can take a second well-known bus name, say org.freedesktop.Telepathy.Client.Empathy._1._42.Bundle1, and configure an object at /org/freedesktop/Telepathy/Client/Empathy/_1/_42/Bundle1 with BypassApproval = TRUE, whose <tp:member-ref>HandlerChannelFilter</tp:member-ref> matches closely related Text channels by their Bundle property. (This is use-case dis5) </tp:rationale>

For service-activatable handlers, this property should be specified in the handler's .client file as follows:

 [org.freedesktop.Telepathy.Client.Handler]
 BypassApproval=true
 
Returns:
A pending variant which will emit finished when the property has been retrieved.
TELEPATHY_QT4_DEPRECATED QStringList Tp::Client::ClientHandlerInterface::Capabilities (  )  const [inline]

Getter for the remote object property "Capabilities".

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

Returns:
The value of the property, or a default-constructed value if the property is not readable.
Tp::PendingVariant* Tp::Client::ClientHandlerInterface::requestPropertyCapabilities (  )  const [inline]

Asynchronous getter for the remote object property "Capabilities" of type QStringList.

The set of additional capabilities supported by this handler. This describes things like support for streamed media codecs and NAT traversal mechanisms: see the Contact Capabilities interface for more details.

For handlers that have a .client file, the channel dispatcher may discover this property from the org.freedesktop.Telepathy.Client.Handler.Capabilities group; for each capability, that group contains a key whose name is the capability, with value true. Keys with other values SHOULD NOT appear in this group.

For instance, the .client file for a streamed media handler that supports ICE-UDP NAT traversal, Speex audio, and Theora and H264 video might contain this group:

 [org.freedesktop.Telepathy.Client.Handler.Capabilities]
 org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/ice-udp=true
 org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/audio/speex=true
 org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/theora=true
 org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/h264=true
 

Like the <tp:member-ref>HandlerChannelFilter</tp:member-ref> property, this property cannot change while the Handler owns its Client bus name. However, the .client file, if any, can change (due to upgrades or installation of pluggable codecs), and the capabilities really supported by the handler might not exactly match what is cached in the .client file.

<tp:rationale>

The client file is installed statically and is intended to list codecs etc. that the handler guarantees it can support (e.g. by having a hard dependency on them), whereas the running handler process might be able to find additional codecs. </tp:rationale>

Returns:
A pending variant which will emit finished when the property has been retrieved.
TELEPATHY_QT4_DEPRECATED Tp::ObjectPathList Tp::Client::ClientHandlerInterface::HandledChannels (  )  const [inline]

Getter for the remote object property "HandledChannels".

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

Returns:
The value of the property, or a default-constructed value if the property is not readable.
Tp::PendingVariant* Tp::Client::ClientHandlerInterface::requestPropertyHandledChannels (  )  const [inline]

Asynchronous getter for the remote object property "HandledChannels" of type Tp::ObjectPathList.

A list of the channels that this process is currently handling.

There is no change notification.

<tp:rationale>

This property exists for state recovery - it makes it possible for channel handling to survive a ChannelDispatcher crash.

If the channel dispatcher is automatically replaced, the replacement can discover all Handlers by looking for the Client well-known bus names, and discover which channels they are currently handling. Once this has been done, all unhandled channels can be re-dispatched, and the only issue visible to the user is that unhandled channels that they have already approved might be sent back to Approvers. </tp:rationale>

The value of this property SHOULD be the same for all Client instances that share a unique bus name, and SHOULD include all channels that are being handled, even if they were conceptually handled by a different Client instance.

<tp:rationale>

Otherwise, when a process released a temporary Client name, channels that it handled because of that Client name would no longer be state-recoverable. </tp:rationale>

Returns:
A pending variant which will emit finished when the property has been retrieved.
Tp::PendingVariantMap* Tp::Client::ClientHandlerInterface::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::Client::ClientHandlerInterface::HandleChannels ( const QDBusObjectPath &  account,
const QDBusObjectPath &  connection,
const Tp::ChannelDetailsList channels,
const Tp::ObjectPathList requestsSatisfied,
qulonglong  userActionTime,
const QVariantMap &  handlerInfo 
) [inline, slot]

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

Called by the channel dispatcher when this client should handle these channels, or when this client should present channels that it is already handling to the user (e.g. bring them into the foreground).

<tp:rationale>

Clients are expected to know what channels they're already handling, and which channel object path corresponds to which window or tab. This can easily be done using a hash table keyed by channels' object paths. </tp:rationale>

This method can raise any D-Bus error. If it does, the handler is assumed to have failed or crashed, and the channel dispatcher MUST recover in an implementation-specific way; it MAY attempt to dispatch the channels to another handler, or close the channels.

If closing the channels, it is RECOMMENDED that the channel dispatcher attempts to close the channels using <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Close</tp:dbus-ref>, but resorts to calling <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Interface.Destroyable.Destroy</tp:dbus-ref> (if available) or ignoring the channel (if not) if the same handler repeatedly fails to handle channels.

After HandleChannels returns successfully, the client process is considered to be responsible for the channel until it its unique name disappears from the bus.

<tp:rationale>

If a process has multiple Client bus names - some temporary and some long-lived - and drops one of the temporary bus names in order to reduce the set of channels that it will handle, any channels that it is already handling should remain unaffected. </tp:rationale>

Parameters:
account The Account with which the channels are associated. The well-known bus name to use is that of the AccountManager.
connection The Connection with which the channels are associated. The well-known bus name to use can be derived from this object path by removing the leading '/' and replacing all subsequent '/' by '.'.
channels The channels and their immutable properties. Their well-known bus name is the same as that of the Connection.
requestsSatisfied 

The requests satisfied by these channels.

<tp:rationale>

If the handler implements Requests, this tells it that these channels match previous <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client.Interface.Requests">AddRequest</tp:dbus-ref> calls that it may have received.

There can be more than one, if they were EnsureChannel requests. </tp:rationale>

Parameters:
userActionTime The time at which user action occurred, or 0 if this channel is to be handled for some reason not involving user action. Handlers SHOULD use this for focus-stealing prevention, if applicable. This property has the same semantic as User_Action_Timestamp but is unsigned for historical reasons.
handlerInfo 

Additional information about these channels. Currently defined keys are:

request-properties - a{oa{sv}}
A map from <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelRequest</tp:dbus-ref> paths listed in Requests_Satisfied to <tp:type>Qualified_Property_Value_Map</tp:type>s containing namespaced immutable properties of each request.

When more keys are defined for this dictionary, all will be optional; handlers MAY safely ignore any entry in this dictionary.

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

Reimplemented from Tp::AbstractInterface.


Property Documentation

Tp::ChannelClassList Tp::Client::ClientHandlerInterface::HandlerChannelFilter [read]

Represents property "HandlerChannelFilter" on the remote object.

A specification of the channels that this channel handler can deal with. It will be offered to approvers as a potential channel handler for bundles that contain only suitable channels, or for suitable channels that must be handled separately.

This property works in exactly the same way as the <tp:dbus-ref namespace="org.freedesktop.Telepathy">Client.Observer.ObserverChannelFilter</tp:dbus-ref> property. In particular, it cannot change while the handler process continues to own the corresponding Client bus name.

In the .client file, it is represented in the same way as ObserverChannelFilter, but the group has the same name as this interface and the keys start with HandlerChannelFilter instead of ObserverChannelFilter.

bool Tp::Client::ClientHandlerInterface::BypassApproval [read]

Represents property "BypassApproval" on the remote object.

If true, channels destined for this handler are automatically handled, without invoking approvers.

<tp:rationale>

The intended usage is to allow a client handling one channel to pick up closely related channels. Suppose a client capable of handling both Text and StreamedMedia, org.freedesktop.Telepathy.Client.Empathy, is handling a StreamedMedia channel. That client can take a second well-known bus name, say org.freedesktop.Telepathy.Client.Empathy._1._42.Bundle1, and configure an object at /org/freedesktop/Telepathy/Client/Empathy/_1/_42/Bundle1 with BypassApproval = TRUE, whose <tp:member-ref>HandlerChannelFilter</tp:member-ref> matches closely related Text channels by their Bundle property. (This is use-case dis5) </tp:rationale>

For service-activatable handlers, this property should be specified in the handler's .client file as follows:

 [org.freedesktop.Telepathy.Client.Handler]
 BypassApproval=true
 
QStringList Tp::Client::ClientHandlerInterface::Capabilities [read]

Represents property "Capabilities" on the remote object.

The set of additional capabilities supported by this handler. This describes things like support for streamed media codecs and NAT traversal mechanisms: see the Contact Capabilities interface for more details.

For handlers that have a .client file, the channel dispatcher may discover this property from the org.freedesktop.Telepathy.Client.Handler.Capabilities group; for each capability, that group contains a key whose name is the capability, with value true. Keys with other values SHOULD NOT appear in this group.

For instance, the .client file for a streamed media handler that supports ICE-UDP NAT traversal, Speex audio, and Theora and H264 video might contain this group:

 [org.freedesktop.Telepathy.Client.Handler.Capabilities]
 org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/ice-udp=true
 org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/audio/speex=true
 org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/theora=true
 org.freedesktop.Telepathy.Channel.Interface.MediaSignalling/video/h264=true
 

Like the <tp:member-ref>HandlerChannelFilter</tp:member-ref> property, this property cannot change while the Handler owns its Client bus name. However, the .client file, if any, can change (due to upgrades or installation of pluggable codecs), and the capabilities really supported by the handler might not exactly match what is cached in the .client file.

<tp:rationale>

The client file is installed statically and is intended to list codecs etc. that the handler guarantees it can support (e.g. by having a hard dependency on them), whereas the running handler process might be able to find additional codecs. </tp:rationale>

Tp::ObjectPathList Tp::Client::ClientHandlerInterface::HandledChannels [read]

Represents property "HandledChannels" on the remote object.

A list of the channels that this process is currently handling.

There is no change notification.

<tp:rationale>

This property exists for state recovery - it makes it possible for channel handling to survive a ChannelDispatcher crash.

If the channel dispatcher is automatically replaced, the replacement can discover all Handlers by looking for the Client well-known bus names, and discover which channels they are currently handling. Once this has been done, all unhandled channels can be re-dispatched, and the only issue visible to the user is that unhandled channels that they have already approved might be sent back to Approvers. </tp:rationale>

The value of this property SHOULD be the same for all Client instances that share a unique bus name, and SHOULD include all channels that are being handled, even if they were conceptually handled by a different Client instance.

<tp:rationale>

Otherwise, when a process released a temporary Client name, channels that it handled because of that Client name would no longer be state-recoverable. </tp:rationale>


Copyright © 2008-2010 Collabora Ltd. and Nokia Corporation
Telepathy-Qt4 0.4.4