This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
An interface for connections in which contacts can be placed in user-defined groups.
The most basic functionality of this interface is to list and monitor
a contact's set of groups. To do this, use the
Looking at contacts' lists of groups is sufficient to present a
user interface resembling XMPP's data model, in which groups behave
like tags applied to contacts, and so an empty group cannot exist
or is not interesting. However, some protocols model groups as
objects in their own right. User interfaces may either track
the set of groups via the
Similarly, in some protocols it is possible to rename a group as
a single atomic operation. Simpler user interfaces will
see the new name being created, the old name being removed, and the
members moving to the new name, via the signals described above.
More advanced user interfaces can optionally distinguish between an
atomic rename and a create/remove pair, and display renamed groups
differently, by monitoring the
This interface also provides various methods to manipulate
user-defined groups, which can be expected to work if
Depending on the protocol, some methods might be implemented by
more than one protocol operation; for instance, in a
"contact-centric" protocol like XMPP,
True if each contact can be in at most one group; false if each contact can be in many groups.
This property cannot change after the connection has moved to the Connected state. Until then, its value is undefined, and it may change at any time, without notification.
Indicates the extent to which contacts' groups can be set and stored.
This property cannot change after the connection has moved to the Connected state. Until then, its value is undefined, and it may change at any time, without notification.
The names of groups of which a contact is a member.
Change notification is via
The names of all groups that currently exist. This may be a
larger set than the union of all contacts' groups
contact attributes, if the connection allows groups to be
empty.
Change notification is via
This property's value is not meaningful until the
Emitted when a group is renamed, in protocols where this can be distinguished from group creation, removal and membership changes.
Immediately after this signal is emitted,
Emitting these extra signals, in this order, means that clients that are interested in the set of groups that exist (but treat a rename and a create/remove pair identically) can ignore the GroupRenamed signal entirely.
If the group was not empty, immediately after those signals are
emitted,
On connection managers where groups behave like tags, renaming a
group MAY be signalled as a set of
On protocols like XMPP, another resource "renaming a group" is indistinguishable from changing contacts' groups individually.
Emitted when one or more groups are removed. If they had members at
the time that they were removed, then immediately after this signal
is emitted,
Emitting the signals in this order allows for two modes of
operation. A client interested only in a contact's set of groups
can ignore
Add the given contact to the given groups (creating new groups if necessary), and remove them from all other groups.
This is the easiest and most correct way to implement user interfaces that display a single contact with a list of groups, resulting in a user expectation that when they apply the changes, the contact's set of groups will become exactly what was displayed.
If the user is removed from a group of which they were the only member, the group MAY be removed automatically.
In protocols like XMPP where groups behave like tags, a group with no members has no protocol representation.
Any
This method SHOULD NOT be called until the
Add the given members to the given group (creating it if necessary), and remove all other members.
This is the easiest and most correct way to implement user interfaces that display a single group with a list of contacts, resulting in a user expectation that when they apply the changes, the groups's set of members will become exactly what was displayed.
If
If the user is removed from a group of which they were the only member, the group MAY be removed automatically.
Any
This method SHOULD NOT be called until the
Add the given members to the given group, creating it if necessary.
If
This is good for user interfaces in which you can edit groups via drag-and-drop.
Any
This method SHOULD NOT be called until the
Remove the given members from the given group.
This is good for user interfaces in which you can edit groups via drag-and-drop.
Any
This method SHOULD NOT be called until the
Remove all members from the given group, then remove the group itself. If the group already does not exist, this method SHOULD return successfully.
Any
This method SHOULD NOT be called until the
Rename the given group.
On protocols where groups behave like tags, this is an API short-cut for adding all of the group's members to a group with the new name, then removing the old group.
Otherwise, clients can't perform this operation atomically, even if the connection could.
Any
This method SHOULD NOT be called until the