| Commit message (Collapse) | Author | Age | Lines |
... | |
| |/ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Several protocols can provide a list of existing chatrooms that a user
is able join. This is crucial for the usage of several protocols, most
notably Purple and Facebook.
Plugins wishing to support this extended functionality must implement
the new prpl->chat_list() function. This implemented function will in
most cases send a remote request for the list of chatrooms. Once the
list of chatrooms is obtained, a bee_chat_info_t GSList must be created
and assigned to the im_connection->chatlist field. Then a call to the
bee_chat_list_finish() is needed to display the list to the user.
The chat list is maintained entirely by the plugin, so it is important
to ensure all pointers related to the chat list remain valid until the
chat list is set to NULL. This list is used internally by bitlbee to
calculate indexes, which then allows the user to join a chat with an
index, rather than some random identifier. It also important to ensure
the list is properly freed whenever it is updated, or when the account
is disconnect via the prpl->logout() function.
On the user interface side of things, the 'chat list' subcommand was
recommissioned. For a user to list the existing chat rooms:
chat list <account id>
Afterwards a user can join a chatroom in the list with its index. This
extends the functionality of the 'chat add' subcommand by adding in
support for the exclamation point operator to denote an index.
chat add <account id> !<index> [channel]
|
| |
| |
| |
| | |
This reverts commit 659df4e333f2f524350dd131e430faaeb66dd91a.
|
| |
| |
| |
| | |
This reverts commit e83d450ef16d9a3783f5daff632c4ac57ceb8fec.
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This allows adding bitlbee-specific purple plugins in a directory
controlled by the user who starts bitlbee (as it can be defined in
bitlbee.conf, PluginDir).
Pidgin and finch have something similar allowing users to place plugins
in ~/.purple/plugins:
path = g_build_filename(purple_user_dir(), "plugins", NULL);
The direct equivalent would be to use our config dir, but i'd rather not
put executable modules there.
|
|\ \ |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Several protocols can provide a list of existing chatrooms that a user
is able join. This is crucial for the usage of several protocols, most
notably Purple and Facebook.
Plugins wishing to support this extended functionality must implement
the new prpl->chat_list() function. This implemented function will in
most cases send a remote request for the list of chatrooms. Once the
list of chatrooms is obtained, a bee_chat_info_t GSList must be created
and assigned to the im_connection->chatlist field. Then a call to the
bee_chat_list_finish() is needed to display the list to the user.
The chat list is maintained entirely by the plugin, so it is important
to ensure all pointers related to the chat list remain valid until the
chat list is set to NULL. This list is used internally by bitlbee to
calculate indexes, which then allows the user to join a chat with an
index, rather than some random identifier. It also important to ensure
the list is properly freed whenever it is updated, or when the account
is disconnect via the prpl->logout() function.
On the user interface side of things, the 'chat list' subcommand was
recommissioned. For a user to list the existing chat rooms:
chat list <account id>
Afterwards a user can join a chatroom in the list with its index. This
extends the functionality of the 'chat add' subcommand by adding in
support for the exclamation point operator to denote an index.
chat add <account id> !<index> [channel]
|
| | | |
|
| | |
| | |
| | |
| | | |
With this aproach it will be simple to add any hash to the scram implementation with some simple boilerplate.
|
| | |
| | |
| | |
| | | |
is not yet used
|
| |/ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Several protocols can provide a list of existing chatrooms that a user
is able join. This is crucial for the usage of several protocols, most
notably Purple and Facebook.
Plugins wishing to support this extended functionality must implement
the new prpl->chat_list() function. This implemented function will in
most cases send a remote request for the list of chatrooms. Once the
list of chatrooms is obtained, a bee_chat_info_t GSList must be created
and assigned to the im_connection->chatlist field. Then a call to the
bee_chat_list_finish() is needed to display the list to the user.
The chat list is maintained entirely by the plugin, so it is important
to ensure all pointers related to the chat list remain valid until the
chat list is set to NULL. This list is used internally by bitlbee to
calculate indexes, which then allows the user to join a chat with an
index, rather than some random identifier. It also important to ensure
the list is properly freed whenever it is updated, or when the account
is disconnect via the prpl->logout() function.
On the user interface side of things, the 'chat list' subcommand was
recommissioned. For a user to list the existing chat rooms:
chat list <account id>
Afterwards a user can join a chatroom in the list with its index. This
extends the functionality of the 'chat add' subcommand by adding in
support for the exclamation point operator to denote an index.
chat add <account id> !<index> [channel]
|
| | |
|
|\ \ |
|
| | |
| | |
| | |
| | | |
With this aproach it will be simple to add any hash to the scram implementation with some simple boilerplate.
|
| | |
| | |
| | |
| | | |
is not yet used
|
| | | |
|
|\ \ \
| | |/
| |/| |
|
| |/
| |
| |
| |
| |
| |
| |
| | |
This will make bitlbee tell the user about the requirement for oauth
when the server actually announces support for oauth. If the server does
not announce oauth support bitlbee will tell the user it doesn't support
any of the schemes provided by the server.
These messages were reversed before.
|
| | |
|
|\| |
|
| |
| |
| |
| |
| | |
This will allow a user to type "like" in Twitter channels,
reflecting recent changes to Twitter itself. Note that the
API hasn't changed.
|
| |
| |
| |
| |
| |
| | |
Plugins which use autotools will install a .la file along with the .so
file. Both of these files are loadable as plugins, so the plugin ends
up being loaded twice. To prevent this, only load the .so module.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As of now, bitlbee will load any plugin regardless of the ABI it was
built against. This is really problematic when structures or symbols
are changed within bitlbee. This often leads to the plugin not loading
or the plugin acting in an undefined way. Typically a simple rebuild of
the plugin will resolve such issues, but many users have no idea that
this is required after they have updated bitlbee.
Furthermore, it is often times impossible to determine the version of
a plugin, without relying on the package manager of the system. This is
quite a problem when users are reporting bugs for external plugins, and
they have no idea what version of the plugin they are running. This is
also an opportunity to provide additional metadata for each plugin that
can then be displayed to the user.
Solving these issues is done by adding a new required function to each
plugin. The init_plugin_info() function must now be implemented along
with the init_plugin() function. This function then returns a static
structure, which retains all of the metadata for the plugin. Then this
is used by bitlbee to check the ABI version and provide information to
the user.
The introduction of the new function is required as bitlbee needs to
obtain the ABI version before calling init_plugin().
The boiler-plate implementation of init_plugin_info():
#ifdef BITLBEE_ABI_VERSION_CODE
struct plugin_info *init_plugin_info(void)
{
static struct plugin_info info = {
BITLBEE_ABI_VERSION_CODE, /* Required */
"plugin-name", /* Required */
"1.3.3.7", /* Required */
"A short description of the plugin", /* Optional */
"First Last <alias@domain.tld>", /* Optional */
"http://www.domain.tld" /* Optional */
};
return &info;
}
#endif
The example wraps the function declaration in an if block for backwards
compatibility with older bitlbee versions.
Displaying the plugin metadata is done via the newly added "plugins"
command, which simply dumps formatted data to the root channel.
|
| |
| |
| |
| |
| |
| | |
Fixes trac ticket 1255, which points out that a strip_html() call down
there may modify the passed string, and some purple plugins may pass
read-only string data to it.
|
| | |
|
|\| |
|
| |
| |
| |
| |
| |
| |
| | |
These only reflect on what arch/cpu bitlbee was built, not on which
it is running. This makes the Debian package unreproducible.
See e.g.
https://tests.reproducible-builds.org/rb-pkg/testing/i386/bitlbee.html
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
it has changed, this is useful for accounts using oauth e.g.
purple-hangouts.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The set account for control channels is now a comma separeted list of
accounts instead of just one. If the user changes the tag of an accounts
trough `account <id> set tag <new_tag>`, the account set will be updated
to reflect this change for all relevant channels. If an account is
removed trough `account <id> delete` it will be removed from the account
set for all relevant channels.
|
| |
| |
| |
| | |
This reverts commit 56fd7212a75237669de37589fc18e2e02444b3d2.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The set account for control channels is now a comma separeted list of
accounts instead of just one. If the user changes the tag of an accounts
trough `account <id> set tag <new_tag>`, the account set will be updated
to reflect this change for all relevant channels. If an account is
removed trough `account <id> delete` it will be removed from the account
set for all relevant channels.
|
| |
| |
| |
| | |
This reverts commit 8ad3c8517ecb1d9ac7cf04236f8634c16b9adde0.
|
| |
| |
| |
| | |
This reverts commit d3e3c73a4b194e666fb3a5f59a0badf6eba292ff.
|
| | |
|
| | |
|