Once the channel has been created you can use the
TpAccountChannelRequest::re-handled: signal to be notified when the channel
has to be re-handled. This can be useful for example to move its window
to the foreground, if applicable.

tp_account_channel_request_set_request_property ()

Configure this channel request to include the given property, as
documented in the Telepathy D-Bus API Specification or an
implementation-specific extension.

Using this method is not recommended, but it can be necessary for
experimental or implementation-specific interfaces.

If the property is not supported by the protocol or channel type, the
channel request will fail. Use TpCapabilities and the Telepathy
D-Bus API Specification to determine which properties are available.

If value is a floating reference, this method takes ownership of it
by using g_variant_ref_sink(). This allows convenient inline use of
GVariant constructors:

tp_account_channel_request_set_file_transfer_description ()

Configure this channel request to provide the recipient of the file
with the given description.

If file descriptions are not supported by the protocol, or if this
method is used on a request that is not actually a file transfer, the
channel request will fail. Use
tp_capabilities_supports_file_transfer_description() to determine
whether outgoing file transfers can have a description.

This function can't be called once self has been used to request a
channel.

tp_account_channel_request_set_file_transfer_initial_offset ()

Configure this channel request to inform the recipient of the file
that this channel will not send the first offset bytes of the file.
In some protocols, this can be used to resume an interrupted transfer.

If this method is not called, the default is to start from the
beginning of the file (equivalent to offset = 0).

If offsets greater than 0 are not supported by the protocol, or if this
method is used on a request that is not actually a file transfer, the
channel request will fail. Use
tp_capabilities_supports_file_transfer_initial_offset() to determine
whether offsets greater than 0 are available.

This function can't be called once self has been used to request a
channel.

tp_account_channel_request_set_file_transfer_timestamp ()

Configure this channel request to accompany the file transfer with
the given modification timestamp for the file.

If file timestamps are not supported by the protocol, or if this
method is used on a request that is not actually a file transfer, the
channel request will fail. Use
tp_capabilities_supports_file_transfer_date() to determine
whether outgoing file transfers can have a timestamp.

This function can't be called once self has been used to request a
channel.

tp_account_channel_request_set_file_transfer_uri ()

Configure this channel request to provide other local Telepathy
components with the URI of the file being sent. Unlike most
properties on a file transfer channel, this information is not
sent to the recipient of the file; instead, it is signalled on
D-Bus for use by other Telepathy components.

The URI should usually be a file URI as defined by
RFC 1738
§3.10 (for instance, file:///path/to/file or
file://localhost/path/to/file). If a remote resource
is being transferred to a contact, it may have a different scheme,
such as http.

Even if this method is used, the connection manager will not read
the file from disk: the handler for the channel is still
responsible for streaming the file. However, providing the URI
allows a local logger to log which file was transferred, for instance.

If this functionality is not supported by the connection manager, or
if this method is used on a request that is not actually a file transfer,
the channel request will fail. Use
tp_capabilities_supports_file_transfer_uri() to determine
whether outgoing file transfers can have a URI.

This function can't be called once self has been used to request a
channel.

the service name that will be used over the tube. It should be a
well-known TCP service name as defined by
http://www.iana.org/assignments/port-numbers or
http://www.dns-sd.org/ServiceTypes.html, for instance "rsync" or "daap".

If the channel already exists and is already being handled, or if a
newly created channel is sent to a different handler, this operation
will fail with the error TP_ERROR_NOT_YOURS. The other handler
will be notified that the channel was requested again (for instance
with "re-handled",
TpBaseClientClassHandleChannelsImpl or "callback"),
and can move its window to the foreground, if applicable.

tp_account_channel_request_create_channel_async ()

Asynchronously calls CreateChannel on the ChannelDispatcher to create a
channel with the properties defined in "request"
and let the ChannelDispatcher dispatch it to an handler.
callback will be called when the channel has been created and dispatched,
or the request has failed.
You can then call tp_account_channel_request_create_channel_finish() to
get the result of the operation.

tp_account_channel_request_ensure_channel_async ()

Asynchronously calls EnsureChannel on the ChannelDispatcher to create a
channel with the properties defined in "request"
and let the ChannelDispatcher dispatch it to an handler.

If a suitable channel already existed, its handler will be notified that
the channel was requested again (for instance with
"re-handled", TpBaseClientClassHandleChannelsImpl
or "callback", if it is implemented using Telepathy-GLib),
so that it can re-present the window to the user, for example.
Otherwise, a new channel will be created and dispatched to a handler.

callback will be called when an existing channel's handler has been
notified, a new channel has been created and dispatched, or the request
has failed.
You can then call tp_account_channel_request_ensure_channel_finish() to
get the result of the operation.

Asynchronously calls CreateChannel on the ChannelDispatcher to create a
channel with the properties defined in "request"
and let the ChannelDispatcher dispatch it to an handler.
callback will be called when the channel has been created and dispatched,
or the request has failed.
You can then call tp_account_channel_request_create_channel_finish() to
get the result of the operation and a TpChannel representing the channel
which has been created. Note that you are not handling
this channel and so should interact with the channel as an Observer.
See
the Telepathy book for details about how clients should interact
with channels.

Asynchronously calls EnsureChannel on the ChannelDispatcher to create a
channel with the properties defined in "request"
and let the ChannelDispatcher dispatch it to an handler.
callback will be called when the channel has been created and dispatched,
or the request has failed.
You can then call tp_account_channel_request_create_channel_finish() to
get the result of the operation and a TpChannel representing the channel
which has been created. Note that you are not handling
this channel and so should interact with the channel as an Observer.
See
the Telepathy book for details about how clients should interact
with channels.

If a suitable channel already existed, its handler will be notified that
the channel was requested again (for instance with
"re-handled", TpBaseClientClassHandleChannelsImpl
or "callback", if it is implemented using Telepathy-GLib),
so that it can re-present the window to the user, for example.
Otherwise, a new channel will be created and dispatched to a handler.

tp_account_channel_request_set_delegated_channel_callback ()

Turn on support for
the org.freedesktop.Telepathy.ChannelRequest.DelegateToPreferredHandler
hint.

When receiving a request containing this hint, self will automatically
delegate the channel to the preferred handler of the request and then call
callback to inform the client that it is no longer handling this channel.

callback may be called any time after (and only after) requesting and
handling the channel (i.e. you have called create_and_handle or
ensure_and_handle).

This function can't be called once self has been used to request a
channel.

If TP_USER_ACTION_TIME_CURRENT_TIME, clients SHOULD behave as though the
user action happened at the current time, e.g. a client may
request that its window gains focus.

On X11-based systems, GDK 2, GDK 3, Clutter 1.0 etc.,
tp_user_action_time_from_x11() can be used to convert an X11 timestamp to
a Telepathy user action time.

If the channel request succeeds, this user action time will be passed on
to the channel's handler. If the handler is a GUI, it may use
tp_user_action_time_should_present() to decide whether to bring its
window to the foreground.

This means that a Telepathy client has made another request for a
matching channel using an "ensure" API like
tp_account_channel_request_ensure_channel_async(), while the channel
still exists. Instead of creating a new channel, the channel dispatcher
notifies the existing handler of channel, resulting in this signal.

Most GUI handlers should respond to this signal by checking
user_action_time, and if appropriate, moving to the foreground.