Home · All Classes · All Namespaces · Modules · Functions · Files |
![]() |
Types generated from the specification representing bit flag constants and combinations of them (bitfields).
QFlags< ConnMgrParamFlag > Tp::ConnMgrParamFlags |
Type representing combinations of ConnMgrParamFlag values.
QFlags< ConnectionAliasFlag > Tp::ConnectionAliasFlags |
Type representing combinations of ConnectionAliasFlag values.
QFlags< AnonymityMode > Tp::AnonymityModeFlags |
Type representing combinations of AnonymityMode values.
Flags for the various types of anonymity modes. These modes are solely to inform the CM of the desired anonymous settings. It is up to the CM to determine whether the anonymity modes should be handled within the CM itself, or whether the network that a CM might be talking to should be enforcing anonymity. CMs MAY support only a subset of these modes, and specific connections MAY support none at all.
QFlags< ConnectionCapabilityFlag > Tp::ConnectionCapabilityFlags |
Type representing combinations of ConnectionCapabilityFlag values.
QFlags< ContactBlockingCapability > Tp::ContactBlockingCapabilities |
Type representing combinations of ContactBlockingCapability values.
QFlags< ContactInfoFlag > Tp::ContactInfoFlags |
Type representing combinations of ContactInfoFlag values.
Flags defining the behaviour of contact information on this protocol. Some protocols provide no information on contacts without an explicit request; others always push information to the connection manager as and when it changes.
QFlags< ContactInfoFieldFlag > Tp::ContactInfoFieldFlags |
Type representing combinations of ContactInfoFieldFlag values.
Flags describing the behaviour of a vCard field.
QFlags< LocationFeature > Tp::LocationFeatures |
Type representing combinations of LocationFeature values.
Flags describing the Location features which may be supported on any given connection.
QFlags< MailNotificationFlag > Tp::MailNotificationFlags |
Type representing combinations of MailNotificationFlag values.
Flags representing capabilities provided by a connection manager. Those values can be used as bitfield. Some flags depend on, or conflict with, each other. Connections SHOULD implement as many of these features as the underlying protocol allows, preferring to implement Supports_Unread_Mails instead of Emits_Mails_Received if both are possible.
QFlags< MediaStreamPending > Tp::MediaStreamPendingSend |
Type representing combinations of MediaStreamPending values.
QFlags< ChannelMediaCapability > Tp::ChannelMediaCapabilities |
Type representing combinations of ChannelMediaCapability values.
The channel-type-specific capability flags used for Channel.Type.StreamedMedia in the Connection.Interface.Capabilities interface. See the InitialAudio property for details of the mechanisms that will replace this.
QFlags< ChannelTextMessageFlag > Tp::ChannelTextMessageFlags |
Type representing combinations of ChannelTextMessageFlag values.
QFlags< ChannelCallState > Tp::ChannelCallStateFlags |
Type representing combinations of ChannelCallState values.
A set of flags representing call states.
QFlags< ChannelGroupFlag > Tp::ChannelGroupFlags |
Type representing combinations of ChannelGroupFlag values.
QFlags< MessagePartSupportFlag > Tp::MessagePartSupportFlags |
Type representing combinations of MessagePartSupportFlag values.
Flags indicating the level of support for message parts on this channel. They are designed such that setting more flags always implies that the channel has more capabilities.
If no flags are set, this indicates that messages may contain a single message part whose content-type is any of the types from SupportedContentTypes, possibly with some alternatives.
There is no flag indicating support for alternatives. This is because the SendMessage implementation can always accept messages containing alternatives, even if the underlying protocol does not, by deleting all alternatives except the first (most preferred) that is supported.
<tp:rationale> Each of the flags so far implies the previous flag, so we could have used a simple enumeration here; however, we've defined the message-part support indicator as a flag set for future expansion. </tp:rationale>
See <tp:member-ref>SupportedContentTypes</tp:member-ref> for some examples.
QFlags< MessageSendingFlag > Tp::MessageSendingFlags |
Type representing combinations of MessageSendingFlag values.
Flags altering the way a message is sent. The "most usual" action should always be to have these flags unset. Some indication of which flags are supported is provided by the DeliveryReportingSupport property.
QFlags< DeliveryReportingSupportFlag > Tp::DeliveryReportingSupportFlags |
Type representing combinations of DeliveryReportingSupportFlag values.
Flags indicating the level of support for delivery reporting on this channel, as found on the DeliveryReportingSupport property. Any future flags added to this set will conform to the convention that the presence of an extra flag implies that more operations will succeed. Note that CMs may always provide more reports than are requested in the Message_Sending_Flags passed to SendMessage. If senders want delivery reports, they should ask for them. If they don't want delivery reports, they can just ignore them, so there's no need to have capability discovery for what will happen if a delivery report isn't requested.
QFlags< ChannelPasswordFlag > Tp::ChannelPasswordFlags |
Type representing combinations of ChannelPasswordFlag values.
QFlags< PropertyFlag > Tp::PropertyFlags |
Type representing combinations of PropertyFlag values.
enum Tp::ConnMgrParamFlag |
Flag type generated from the specification.
ConnMgrParamFlagRequired |
This parameter is required for connecting to the server. |
ConnMgrParamFlagRegister |
This parameter is required for registering an account on the server. |
ConnMgrParamFlagHasDefault |
This parameter has a default value, which is returned in GetParameters; not providing this parameter is equivalent to providing the default. |
ConnMgrParamFlagSecret |
This parameter should be considered private or secret; for instance, clients should store it in a "password safe" like gnome-keyring or kwallet, omit it from debug logs, and use a text input widget that hides the value of the parameter. (Clients that support older connection managers may also treat any parameter whose name contains "password" as though it had this flag.) |
ConnMgrParamFlagDBusProperty |
This parameter is also a D-Bus property on the resulting <tp:dbus-ref namespace="ofdT">Connection</tp:dbus-ref>; a parameter named When a new value for a parameter with this flag is passed to <tp:dbus-ref namespace="ofdT">Account.UpdateParameters</tp:dbus-ref>, the account manager will attempt to update its value on any running connections. Similarly, if the parameter also has the <tp:rationale> This allows runtime-configurable options to be stored and maintained by the <tp:dbus-ref namespace="ofdT">AccountManager</tp:dbus-ref>, without needing to invent a separate account preference for “properties that should be set on the connection as soon as it is created”. It was originally invented to manage <tp:dbus-ref namespace="ofdT.Connection.Interface">Cellular</tp:dbus-ref> preferences. </tp:rationale> |
_ConnMgrParamFlagPadding |
Flag type generated from the specification.
enum Tp::AnonymityMode |
Flag type generated from the specification.
Flag type generated from the specification.
enum Tp::ContactInfoFlag |
Flag type generated from the specification.
Flag type generated from the specification.
enum Tp::LocationFeature |
Flag type generated from the specification.
MailNotificationFlagSupportsUnreadMailCount |
This Connection provides the number of unread e-mails (or e-mail threads) in the main folder of your e-mail account, as the UnreadMailCount property. The connection manager will update this value by emitting the UnreadMailsChanged signal. |
MailNotificationFlagSupportsUnreadMails |
This Connection provides a detailed list of unread e-mails, as the UnreadMails property. If this flag is set, Supports_Unread_Mail_Count MUST be set, and Emits_Mails_Received MUST NOT be set. The Connection will update the list by emitting the UnreadMailsChanged signals. |
MailNotificationFlagEmitsMailsReceived |
This Connection emits the MailsReceived signal, which provides details about newly arrived e-mails but does not maintain their read/unread status afterwards. This flag MUST NOT be combined with Supports_Unread_Mails. |
MailNotificationFlagSupportsRequestInboxURL |
This Connection can provide a URL (with optional POST data) to open the the inbox of the e-mail account in a web-based client, via the RequestInboxURL method. |
MailNotificationFlagSupportsRequestMailURL |
This Connection can provide a URL (with optional POST data) to open a specific mail in a web-based client, via the <tp:member-ref>RequestMailURL</tp:member-ref> method. This feature is not useful unless either Emits_Mails_Received or Supports_Unread_Mails is set. If this flag is not set, clients SHOULD fall back to using <tp:member-ref>RequestInboxURL</tp:member-ref> if available. |
MailNotificationFlagThreadBased |
Each <tp:type>Mail</tp:type> represents a thread of e-mails, which MAY have more than one sender. <tp:rationale> Google Talk notifies users about new mail in terms of unread threads, rather than unread e-mails. </tp:rationale> |
_MailNotificationFlagPadding |
Flag type generated from the specification.
Flag type generated from the specification.
Flag type generated from the specification.
ChannelTextMessageFlagTruncated |
The incoming message was truncated to a shorter length by the server or the connection manager. |
ChannelTextMessageFlagNonTextContent |
The incoming message contained non-text content which cannot be represented by this interface, but has been signalled in the <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface">Messages</tp:dbus-ref> interface. Connection managers SHOULD only set this flag if the non-text content appears to be relatively significant (exactly how significant is up to the implementor). The intention is that if this flag is set, clients using this interface SHOULD inform the user that part of the message was not understood. |
ChannelTextMessageFlagScrollback |
The incoming message was part of a replay of message history. <tp:rationale> In XMPP multi-user chat, a few past messages are replayed when you join a chatroom. A sufficiently capable IRC connection manager could also set this flag on historical messages when connected to a proxy like bip or irssi-proxy. The existence of this flag allows loggers and UIs to use better heuristics when eliminating duplicates (a simple implementation made possible by this flag would be to avoid logging scrollback at all). </tp:rationale> |
ChannelTextMessageFlagRescued |
The incoming message has been seen in a previous channel during the lifetime of the <tp:dbus-ref namespace="org.freedesktop.Telepathy">Connection</tp:dbus-ref>, but had not been acknowledged when that channel closed, causing an identical channel (the channel in which the message now appears) to open. <tp:rationale> This means that a logger (which should already have seen the message in the previous channel) is able to recognise and ignore these replayed messages. </tp:rationale> |
_ChannelTextMessageFlagPadding |
enum Tp::ChannelCallState |
Flag type generated from the specification.
enum Tp::ChannelGroupFlag |
Flag type generated from the specification.
ChannelGroupFlagCanAdd |
The AddMembers method can be used to add or invite members who are not already in the local pending list (which is always valid). |
ChannelGroupFlagCanRemove |
The RemoveMembers method can be used to remove channel members (removing those on the pending local list is always valid). |
ChannelGroupFlagCanRescind |
The RemoveMembers method can be used on people on the remote pending list. |
ChannelGroupFlagMessageAdd |
A message may be sent to the server when calling AddMembers on contacts who are not currently pending members. |
ChannelGroupFlagMessageRemove |
A message may be sent to the server when calling RemoveMembers on contacts who are currently channel members. |
ChannelGroupFlagMessageAccept |
A message may be sent to the server when calling AddMembers on contacts who are locally pending. |
ChannelGroupFlagMessageReject |
A message may be sent to the server when calling RemoveMembers on contacts who are locally pending. |
ChannelGroupFlagMessageRescind |
A message may be sent to the server when calling RemoveMembers on contacts who are remote pending. |
ChannelGroupFlagChannelSpecificHandles |
The members of this group have handles which are specific to this channel, and are not valid as general-purpose handles on the connection. Depending on the channel, it may be possible to check the <tp:member-ref>HandleOwners</tp:member-ref> property or call <tp:member-ref>GetHandleOwners</tp:member-ref> to find the owners of these handles, which should be done if you wish to (e.g.) subscribe to the contact's presence. Connection managers must ensure that any given handle is not simultaneously a general-purpose handle and a channel-specific handle. |
ChannelGroupFlagOnlyOneGroup |
Placing a contact in multiple groups of this type is not allowed and will raise NotAvailable (on services where contacts may only be in one user-defined group, user-defined groups will have this flag). |
ChannelGroupFlagHandleOwnersNotAvailable |
In rooms with channel specific handles (ie Channel_Specific_Handles flag is set), this flag indicates that no handle owners are available, apart from the owner of the SelfHandle. This used to be an important optimization to avoid repeated GetHandleOwners calls, before we introduced the HandleOwners property and HandleOwnersChanged signal. |
ChannelGroupFlagProperties |
This flag indicates that all the properties introduced in specification 0.17.6 are fully supported. |
ChannelGroupFlagMembersChangedDetailed |
Indicates that MembersChangedDetailed will be emitted for changes to this group's members in addition to MembersChanged. Clients can then connect to the former and ignore emission of the latter. This flag's state MUST NOT change over the lifetime of a channel. If it were allowed to change, client bindings would have to always connect to MembersChanged just in case the flag ever went away (and generally be unnecessarily complicated), which would mostly negate the point of having this flag in the first place. |
ChannelGroupFlagMessageDepart |
A message may be sent to the server when calling RemoveMembers on the SelfHandle. This would be set for XMPP Multi-User Chat or IRC channels, but not for a typical implementation of streamed media calls. |
_ChannelGroupFlagPadding |
Flag type generated from the specification.
Flag type generated from the specification.
Flag type generated from the specification.
enum Tp::PropertyFlag |
Copyright © 2008-2011 Collabora Ltd. and Nokia Corporation | Telepathy-Qt4 0.6.1 |