| Top | |
|
|
|
This allows contacts to be collected into user-defined groups (or categories) for organisational purposes. Groups are non-exclusive and non-hierarchical, so a single contact can be put into many groups, but groups may not themselves be put into groups.
The reason a group member has changed its membership in the group.
These closely follow the Channel_Group_Change_Reason interface in the Telepathy specification.
|
No reason was provided for this change. This is used when a member joins or leaves a group normally. |
||
|
The change is due to a member going offline. Also used when member is already offline, but this wasn't known previously. |
||
|
The change is due to a kick operation. |
||
|
The change is due to a busy indication. |
||
|
The change is due to an invitation. |
||
|
The change is due to a kick+ban operation. |
||
|
The change is due to an error occurring. |
||
|
The change is because the requested member does not exist. For instance, if the user invites a nonexistent contact to a chatroom or attempts to call a nonexistent contact |
||
|
The change is because the requested contact did not respond. |
||
|
The change is because a member's unique identifier changed. There must be exactly one member in the removed set and exactly one member in one of the added sets. |
||
|
The change is because there was no permission to contact the requested member. |
||
|
If members are removed with this reason code, the change is because the group has split into unconnected parts which can only communicate within themselves (e.g. netsplits on IRC use this reason code). If members are added with this reason code, the change is because unconnected parts of the group have rejoined. If this channel carries messages (e.g. Text or Tubes channels) applications must assume that the contacts being added are likely to have missed some messages as a result of the separation, and that the contacts in the group are likely to have missed some messages from the contacts being added. Note that from the added contacts' perspective, they have been in the group all along, and the contacts we indicate to be in the group (including the local user) have just rejoined the group with reason Separated. Application protocols in Tubes should be prepared to cope with this situation. |
typedef struct _FolksGroupDetails FolksGroupDetails;
Groups for a contact.
This allows contacts to be collected into user-defined groups (or categories) for organisational purposes. Groups are non-exclusive and non-hierarchical, so a single contact can be put into many groups, but groups may not themselves be put into groups.
struct FolksGroupDetailsIface {
GTypeInterface parent_iface;
void (*change_group) (FolksGroupDetails* self, const gchar* group, gboolean is_member, GAsyncReadyCallback _callback_, gpointer _user_data_);
void (*change_group_finish) (FolksGroupDetails* self, GAsyncResult* _res_, GError** error);
void (*change_groups) (FolksGroupDetails* self, GeeSet* groups, GAsyncReadyCallback _callback_, gpointer _user_data_);
void (*change_groups_finish) (FolksGroupDetails* self, GAsyncResult* _res_, GError** error);
GeeSet* (*get_groups) (FolksGroupDetails* self);
void (*set_groups) (FolksGroupDetails* self, GeeSet* value);
};
Interface for creating FolksGroupDetails implementations.
the parent interface structure |
||
virtual method called by |
||
asynchronous finish function for |
||
virtual method called by |
||
asynchronous finish function for |
||
getter method for the abstract property "groups" |
||
setter method for the abstract property "groups" |