Flags¶
Details¶
- class TelepathyGLib.AnonymityModeFlags(value)¶
Bases:
GLib.Flags
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.
Bitfield/set of flags generated from the Telepathy specification.
- CLIENT_INFO = 1¶
Obscure any information that provides user identification, user-agent identification or personal details. Examples of this information might be GSM CallerID, SIP from address, various informational email headers, etc. The CM should scrub/replace any of this information before passing messages or data onto the network. Note that a CM which has the option of obscuring the information at the CM or privacy service level would choose both (anonymity services are opaque to clients of this interface). Clients SHOULD NOT set both Client_Info and Show_Client_Info modes. If they are set, the CM MUST respect Client_Info and ignore Show_Client_Info.
- SHOW_CLIENT_INFO = 2¶
Explicitly request showing of client information. In connection context, this can be used to override service default. In channel context, this overrides connection anonymity modes. In GSM, it’s possible to have CLIR enabled by default, and explicitly suppress CLIR for a single phone call. Clients SHOULD NOT set both Client_Info and Show_Client_Info modes. If they are set, the CM MUST respect Client_Info and ignore Show_Client_Info. The CM MAY set both Client_Info and Show_Client_Info in SupportedAnonymityModes to indicate its support for explicitly hiding and publicising client information.
- NETWORK_INFO = 4¶
Obscure any originating IP address information, contact URIs, and anonymize all traffic involved with sending/receiving any media streams or call content. Examples of this include the “headers” portions of RFC 3323 as well as the History-Info (described in RFC 4244) for a SIP CM. This SHOULD have the effect of hiding address information from the remote contact (ie, the contact cannot know what IP address the session is originated from). Obviously the network still needs to be able to route information between contacts, so this provides no guarantees of what can be seen by intermediaries.
- class TelepathyGLib.CallFlags(value)¶
Bases:
GLib.Flags
A set of flags representing additional information than is available in CallState. Many of these flags only make sense in a particular (or may explain why a call is in a specific state).
Bitfield/set of flags generated from the Telepathy specification.
- LOCALLY_HELD = 1¶
The call has been put on hold by the local user, e.g. using the Hold interface. This flag SHOULD only be set if there is at least one Content, and all Contents are locally held. Otherwise, in transient situations where some but not all contents are on hold, UIs would falsely indicate that the call as a whole is on hold, which could lead to the user saying something they’ll regret, while under the impression that the other contacts can’t hear them! This flag exists as a simplified proxy for HoldStateChanged, to reduce the number of signals that need to be listened to by a simple UI.
- CLEARING = 16¶
This flag only occurs when the CallState is Ended. The call with this flag set has ended, but not all resources corresponding to the call have been freed yet. Depending on the protocol there might be some audible feedback while the clearing flag is set. In calls following the ITU-T Q.931 standard there is a period of time between the call ending and the underlying channel being completely free for re-use.
- LOCALLY_RINGING = 2¶
This flag exists for observability of the SetRinging method (e.g. so that loggers can tell whether the call got as far as alerting the user, or whether something went wrong before then). It should be set when the SetRinging is called, and unset when the call leaves Initialised.
- LOCALLY_QUEUED = 4¶
This flag exists for observability of the SetQueued method. It should be set when the SetQueued is called, and unset when the call leaves Initialising or Initialised.
- FORWARDED = 8¶
The initiator of the call originally called a contact other than the current recipient of the call, but the call was then forwarded or diverted. This flag only makes sense on outgoing calls. It SHOULD be set or unset according to informational messages from other contacts.
- class TelepathyGLib.CallMemberFlags(value)¶
Bases:
GLib.Flags
A set of flags representing the status of a remote contact in a call. It is protocol- and client-specific whether a particular contact will ever have a particular flag set on them, and Telepathy clients SHOULD NOT assume that a flag will ever be set. 180 Ringing in SIP, and its equivalent in XMPP, are optional informational messages, and implementations are not required to send them. The same applies to the messages used to indicate hold state.
Bitfield/set of flags generated from the Telepathy specification.
- RINGING = 1¶
The remote contact’s client has told us that the contact has been alerted about the call but has not responded. This is a flag per member, not a flag for the call as a whole, because in Muji conference calls, you could invite someone and have their state be “ringing” for a while.
- HELD = 2¶
The call member has put this call on hold. This is a flag per member, not a flag for the call as a whole, because in conference calls, any member could put the conference on hold.
- CONFERENCE_HOST = 4¶
This contact has merged this call into a conference. Note that GSM provides a notification when the remote party merges a call into a conference, but not when it is split out again; thus, this flag can only indicate that the call has been part of a conference at some point. If a GSM connection manager receives a notification that a call has been merged into a conference a second time, it SHOULD represent this by clearing and immediately re-setting this flag on the remote contact.
- class TelepathyGLib.CaptchaFlags(value)¶
Bases:
GLib.Flags
Extra flags to include with Captcha information
Bitfield/set of flags generated from the Telepathy specification.
- CAPTCHA_FLAGS_REQUIRED = 1¶
This captcha mechanism is required to be successfully answered in order to pass this captcha challenge.
- class TelepathyGLib.ChannelCallStateFlags(value)¶
Bases:
GLib.Flags
A set of flags representing call states.
Bitfield/set of flags generated from the Telepathy specification.
- RINGING = 1¶
The contact has been alerted about the call but has not responded (e.g. 180 Ringing in SIP).
- IN_PROGRESS = 16¶
Progress has been made in placing the outgoing call, but the destination contact may not have been made aware of the call yet (so the Ringing state is not appropriate). This corresponds to SIP’s status code 183 Session Progress, and could be used when the outgoing call has reached a gateway, for instance.
- QUEUED = 2¶
The contact is temporarily unavailable, and the call has been placed in a queue (e.g. 182 Queued in SIP, or call-waiting in telephony).
- CONFERENCE_HOST = 32¶
This contact has merged this call into a conference. Note that GSM provides a notification when the remote party merges a call into a conference, but not when it is split out again; thus, this flag can only indicate that the call has been part of a conference at some point. If a GSM connection manager receives a notification that a call has been merged into a conference a second time, it SHOULD represent this by clearing and immediately re-setting this flag on the remote contact.
- HELD = 4¶
The contact has placed the call on hold, and will not receive media from the local user or any other participants until they unhold the call again.
- FORWARDED = 8¶
The initiator of the call originally called a contact other than the current recipient of the call, but the call was then forwarded or diverted.
- class TelepathyGLib.ChannelGroupFlags(value)¶
Bases:
GLib.Flags
Bitfield/set of flags generated from the Telepathy specification.
- CAN_ADD = 1¶
The AddMembers method can be used to add or invite members who are not already in the local pending list (which is always valid).
- HANDLE_OWNERS_NOT_AVAILABLE = 1024¶
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.
- MESSAGE_RESCIND = 128¶
A message may be sent to the server when calling RemoveMembers on contacts who are remote pending.
- MESSAGE_REMOVE = 16¶
A message may be sent to the server when calling RemoveMembers on contacts who are currently channel members.
- CAN_REMOVE = 2¶
The RemoveMembers method can be used to remove channel members (removing those on the pending local list is always valid).
- PROPERTIES = 2048¶
This flag indicates that all the properties introduced in specification 0.17.6 are fully supported.
- CHANNEL_SPECIFIC_HANDLES = 256¶
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 HandleOwners property or call GetHandleOwners 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.
- MESSAGE_ACCEPT = 32¶
A message may be sent to the server when calling AddMembers on contacts who are locally pending.
- CAN_RESCIND = 4¶
The RemoveMembers method can be used on people on the remote pending list.
- MEMBERS_CHANGED_DETAILED = 4096¶
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.
- ONLY_ONE_GROUP = 512¶
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).
- MESSAGE_REJECT = 64¶
A message may be sent to the server when calling RemoveMembers on contacts who are locally pending.
- MESSAGE_ADD = 8¶
A message may be sent to the server when calling AddMembers on contacts who are not currently pending members.
- MESSAGE_DEPART = 8192¶
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.
- class TelepathyGLib.ChannelMediaCapabilities(value)¶
Bases:
GLib.Flags
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.
Bitfield/set of flags generated from the Telepathy specification.
- AUDIO = 1¶
The handle is capable of using audio streams within a media channel.
- NAT_TRAVERSAL_ICE_UDP = 16¶
The handle is capable of establishing ICE UDP peer-to-peer connections (as defined by the IETF MMUSIC working group) to traverse NATs.
- VIDEO = 2¶
The handle is capable of using video streams within a media channel.
- IMMUTABLE_STREAMS = 32¶
Channels whose target handle is this contact will have ImmutableStreams = True.
- NAT_TRAVERSAL_STUN = 4¶
The handle is capable of performing STUN to traverse NATs.
- NAT_TRAVERSAL_GTALK_P2P = 8¶
The handle is capable of establishing Google Talk peer-to-peer connections (as implemented in libjingle 0.3) to traverse NATs.
- class TelepathyGLib.ChannelPasswordFlags(value)¶
Bases:
GLib.Flags
Bitfield/set of flags generated from the Telepathy specification.
- HINT = 4¶
The RoomConfig1.PasswordHint contains a hint for the password.
- PROVIDE = 8¶
The ProvidePassword method must be called now for the user to join the channel
- class TelepathyGLib.ChannelTextMessageFlags(value)¶
Bases:
GLib.Flags
Bitfield/set of flags generated from the Telepathy specification.
- TRUNCATED = 1¶
The incoming message was truncated to a shorter length by the server or the connection manager.
- NON_TEXT_CONTENT = 2¶
The incoming message contained non-text content which cannot be represented by this interface, but has been signalled in the Messages 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.
- SCROLLBACK = 4¶
The incoming message was part of a replay of message history. 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).
- RESCUED = 8¶
The incoming message has been seen in a previous channel during the lifetime of the Connection, but had not been acknowledged when that channel closed, causing an identical channel (the channel in which the message now appears) to open. 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.
- class TelepathyGLib.ConnMgrParamFlags(value)¶
Bases:
GLib.Flags
Bitfield/set of flags generated from the Telepathy specification.
- REQUIRED = 1¶
This parameter is required for connecting to the server.
- DBUS_PROPERTY = 16¶
This parameter is also a D-Bus property on the resulting Connection; a parameter named com.example.Duck.Macaroni with this flag corresponds to the Macaroni property on the com.example.Duck interface. Its value can be queried and possibly changed on an existing Connection using methods on the org.freedesktop.DBus.Properties interface. When a new value for a parameter with this flag is passed to Account.UpdateParameters, the account manager will attempt to update its value on any running connections. Similarly, if the parameter also has the Has_Default flag, and is passed in the second argument to UpdateParameters, the default value will be applied to any running connections. Thus, clients generally do not need to directly access or update the connection property; instead, they SHOULD manipulate Account.Parameters. This allows runtime-configurable options to be stored and maintained by the AccountManager, 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 Cellular preferences.
- REGISTER = 2¶
This parameter is required for registering an account on the server.
- HAS_DEFAULT = 4¶
This parameter has a default value, which is returned in GetParameters; not providing this parameter is equivalent to providing the default.
- SECRET = 8¶
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.)
- class TelepathyGLib.ConnectionAliasFlags(value)¶
Bases:
GLib.Flags
Bitfield/set of flags generated from the Telepathy specification.
- CONNECTION_ALIAS_FLAG_USER_SET = 1¶
The aliases of contacts on this connection may be changed by the user of the service, not just by the contacts themselves. This is the case on Jabber, for instance. It is possible that aliases can be changed by the contacts too - which alias takes precedence is not defined by this specification, and depends on the server and/or connection manager implementation. This flag only applies to the aliases of “globally valid” contact handles. At this time, clients should not expect to be able to change the aliases corresponding to any channel-specific handles. If this becomes possible in future, a new flag will be defined.
- class TelepathyGLib.ConnectionCapabilityFlags(value)¶
Bases:
GLib.Flags
Bitfield/set of flags generated from the Telepathy specification.
- CREATE = 1¶
The given channel type and handle can be given to RequestChannel to create a new channel of this type.
- INVITE = 2¶
The given contact can be invited to an existing channel of this type.
- class TelepathyGLib.ContactBlockingCapabilities(value)¶
Bases:
GLib.Flags
Bitfield/set of flags generated from the Telepathy specification.
- CONTACT_BLOCKING_CAPABILITY_CAN_REPORT_ABUSIVE = 1¶
When calling BlockContacts, the contacts may be reporting as abusive to the server administrators by setting Report_Abusive to True.
- class TelepathyGLib.ContactInfoFieldFlags(value)¶
Bases:
GLib.Flags
Flags describing the behaviour of a vCard field.
Bitfield/set of flags generated from the Telepathy specification.
- PARAMETERS_EXACT = 1¶
If present, exactly the parameters indicated must be set on this field; in the case of an empty list of parameters, this implies that parameters may not be used. If absent, and the list of allowed parameters is non-empty, any (possibly empty) subset of that list may be used. If absent, and the list of allowed parameters is empty, any parameters may be used.
- OVERWRITTEN_BY_NICKNAME = 2¶
Indicates that this field will be overwritten when the user’s alias is changed with SetAliases or when the Account’s Nickname is updated. Clients that allow the editing of the Alias and the ContactInfo in the same location should hide fields with this flag. If a client allowed the user to edit both the nickname and the ContactInfo field at the same time, the user could set them to two different values even though they map to the same property. This would result in surprising behavior where the second value would win over the first. In addition to hiding this field when editing ContactInfo together with the user’s nickname, it is recommended that clients call SetContactInfo before setting the user’s nickname. This ensures that if the user changes the nickname, the correct value will get set even if the stale nickname is mistakenly sent along with SetContactInfo. If used, this flag typically appears on either the ‘nickname’ or ‘fn’ field.
- class TelepathyGLib.ContactInfoFlags(value)¶
Bases:
GLib.Flags
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.
Bitfield/set of flags generated from the Telepathy specification.
- CAN_SET = 1¶
Indicates that SetContactInfo is supported on this connection.
- PUSH = 2¶
Indicates that the protocol pushes all contacts’ information to the connection manager without prompting. If set, ContactInfoChanged will be emitted whenever contacts’ information changes.
- class TelepathyGLib.DBusNameType(value)¶
Bases:
GLib.Flags
A set of flags indicating which D-Bus bus names are acceptable. They can be combined with the bitwise-or operator to accept multiple types.
TelepathyGLib.DBusNameType.NOT_BUS_DAEMON
andTelepathyGLib.DBusNameType.ANY
are the bitwise-or of other appropriate types, for convenience.Since 0.11.5, there is a corresponding
GObject.FlagsClass
type, %TP_TYPE_DBUS_NAME_TYPE.New in version 0.7.1.
- UNIQUE = 1¶
accept unique names like :1.123 (not including the name of the bus daemon itself)
- WELL_KNOWN = 2¶
accept well-known names like com.example.Service (not including the name of the bus daemon itself)
- NOT_BUS_DAEMON = 3¶
accept either unique or well-known names, but not the bus daemon
- BUS_DAEMON = 4¶
accept the name of the bus daemon itself, which has the syntax of a well-known name, but behaves like a unique name
- ANY = 7¶
accept any of the above
- class TelepathyGLib.DBusPropertiesMixinFlags(value)¶
Bases:
GLib.Flags
Bitfield representing allowed access to a property. At most one of
TelepathyGLib.DBusPropertiesMixinFlags.EMITS_CHANGED
andTelepathyGLib.DBusPropertiesMixinFlags.EMITS_INVALIDATED
may be specified for a property.Since 0.11.5, there is a corresponding
GObject.FlagsClass
type, %TP_TYPE_DBUS_PROPERTIES_MIXIN_FLAGS.New in version 0.7.3.
- READ = 1¶
The property can be read using Get and GetAll
- WRITE = 2¶
The property can be written using Set
- EMITS_CHANGED = 4¶
The property’s new value is included in emissions of PropertiesChanged
- EMITS_INVALIDATED = 8¶
The property is announced as invalidated, without its value, in emissions of PropertiesChanged
- class TelepathyGLib.DeliveryReportingSupportFlags(value)¶
Bases:
GLib.Flags
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.
Bitfield/set of flags generated from the Telepathy specification.
- FAILURES = 1¶
Clients MAY expect to receive negative delivery reports if Message_Sending_Flag_Report_Delivery is specified when sending.
- SUCCESSES = 2¶
Clients MAY expect to receive positive delivery reports if Message_Sending_Flag_Report_Delivery is specified when sending.
- READ = 4¶
Clients MAY expect to receive Delivery_Status Read reports if Message_Sending_Flag_Report_Read is specified when sending.
- DELETED = 8¶
Clients MAY expect to receive Delivery_Status Deleted reports if Message_Sending_Flag_Report_Deleted is specified when sending.
- class TelepathyGLib.LocationFeatures(value)¶
Bases:
GLib.Flags
Flags describing the Location features which may be supported on any given connection.
Bitfield/set of flags generated from the Telepathy specification.
- LOCATION_FEATURE_CAN_SET = 1¶
Indicates that setting your own location with SetLocation is supported on this connection.
- class TelepathyGLib.MailNotificationFlags(value)¶
Bases:
GLib.Flags
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.
Bitfield/set of flags generated from the Telepathy specification.
- SUPPORTS_UNREAD_MAIL_COUNT = 1¶
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.
- SUPPORTS_REQUEST_MAIL_URL = 16¶
This Connection can provide a URL (with optional POST data) to open a specific mail in a web-based client, via the RequestMailURL 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 RequestInboxURL if available.
- SUPPORTS_UNREAD_MAILS = 2¶
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.
- THREAD_BASED = 32¶
Each Mail represents a thread of e-mails, which MAY have more than one sender. Google Talk notifies users about new mail in terms of unread threads, rather than unread e-mails.
- EMITS_MAILS_RECEIVED = 4¶
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.
- SUPPORTS_REQUEST_INBOX_URL = 8¶
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.
- class TelepathyGLib.MediaStreamPendingSend(value)¶
Bases:
GLib.Flags
Bitfield/set of flags generated from the Telepathy specification.
- LOCAL_SEND = 1¶
The local user has been asked to send media by the remote user. Call RequestStreamDirection to indicate whether or not this is acceptable.
- REMOTE_SEND = 2¶
The remote user has been asked to send media by the local user. The StreamDirectionChanged signal will be emitted when the remote user accepts or rejects this change.
- class TelepathyGLib.MessagePartSupportFlags(value)¶
Bases:
GLib.Flags
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. 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. See SupportedContentTypes for some examples.
Bitfield/set of flags generated from the Telepathy specification.
- ONE_ATTACHMENT = 1¶
SendMessage will accept messages containing a textual message body, plus a single attachment of any type listed in the SupportedContentTypes property. It does not make sense for this flag to be set if Message_Part_Support_Flag_Data_Only is not also set (because the connection manager can trivially provide an empty text part if necessary).
- MULTIPLE_ATTACHMENTS = 2¶
SendMessage will accept messages containing a textual message body, plus an arbitrary number of attachments of any type listed in the SupportedContentTypes property. It does not make sense for this flag to be set if Message_Part_Support_Flag_One_Attachment is not also set.
- class TelepathyGLib.MessageSendingFlags(value)¶
Bases:
GLib.Flags
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.
Bitfield/set of flags generated from the Telepathy specification.
- DELIVERY = 1¶
Provide a successful delivery report if possible, even if this is not the default for this protocol. Ignored if delivery reports are not possible on this protocol. In some protocols, like XMPP, it is not conventional to request or send positive delivery notifications. Delivery failure reports SHOULD always be sent, but if this flag is present, the connection manager MAY also try harder to obtain failed delivery reports or allow them to be matched to outgoing messages.
- READ = 2¶
Provide a delivery report when the message is read by the recipient, even if this is not the default for this protocol. Ignored if read reports are not possible on this protocol.
- DELETED = 4¶
Provide a delivery report when the message is deleted by the recipient, even if this is not the default for this protocol. Ignored if such reports are not possible on this protocol.
- class TelepathyGLib.PropertyFlags(value)¶
Bases:
GLib.Flags
Bitfield/set of flags generated from the Telepathy specification.
- READ = 1¶
The property can be read
- WRITE = 2¶
The property can be written
- class TelepathyGLib.RTCPXRStatisticsFlags(value)¶
Bases:
GLib.Flags
Bitfield/set of flags generated from the Telepathy specification.
- LOSS = 1¶
Loss report flag, as defined in RFC3611 section 4.6.
- HL = 16¶
Second bit of TTL or Hop Limit flag, as defined in RFC3611 section 4.6.
- DUPLICATE = 2¶
Duplicate report flag, as defined in RFC3611 section 4.6.
- JITTER = 4¶
Jitter flag, as defined in RFC3611 section 4.6.
- TTL = 8¶
First bit of TTL or Hop Limit flag, as defined in RFC3611 section 4.6.
- class TelepathyGLib.StorageRestrictionFlags(value)¶
Bases:
GLib.Flags
Flags indicating restrictions imposed on an Account by its storage method.
Bitfield/set of flags generated from the Telepathy specification.
- PARAMETERS = 1¶
The account’s Parameters property can’t be changed by calling UpdateParameters.
- ENABLED = 2¶
The account can’t be enabled/disabled by setting the Enabled property.
- PRESENCE = 4¶
The account’s presence can’t be changed by setting the RequestedPresence and AutomaticPresence properties.
- SERVICE = 8¶
The account’s Service property cannot be changed.