Commit Graph

16 Enmetoj

Author SHA1 Message Date
Jaidyn Ann 373dcb4a58 Protocol message tweaks, bump API version
Some chat protocol messages' names have been changed to more fitting or
consistent names― e.g., "IM_AVATAR_SET" to "IM_USER_AVATAR_SET", or
"IM_CONTACT_LIST_*" to "IM_ROSTER_*" (to agree with Cardie's usage of
the word).

The API version has been bumped― for the forseeable future (at least
several months, I promise!) no compatibility-breaking changes will be
introduced. Until then, any new feautures or message slots will be
additive and optional.
2021-08-08 21:01:42 -05:00
Jaidyn Ann 6875c3cb75 (purple) Localization, init catkeys 2021-07-18 21:51:38 -05:00
Jaidyn Ann 4905dbbe6c Redesign add-on disconnection
Currently, add-ons are disconnected when ChatProtocol::Shutdown() is
called, which the add-on can do by itself― but there is no standard way
for add-ons to notify the app about their Shutdown. Because of this,
they tend to not call Shutdown()― instead (as in the case of the Jabber
add-on), they display a BAlert (IM_ERROR) notifying the user of the
connection error, but the account is considered active by Cardie (and
its threads are still existant, including its ProtocolLooper).

Zombies are bad, so this is redesigned somewhat with this commit:
Protocols should no longer call ChatProtocol::Shutdown() themselves,
they must send an IM_MESSAGE of IM_PROTOCOL_DISABLE to the app.

This will delete its ProtocolLooper, which in turn will send a
notification to the user and delete the ChatProtocol, and so
calling ChatProtocol::Shutdown().

In the included protocols, an IM_ERROR is sent right before
IM_PROTOCOL_DISABLE is sent if due to a connection error. This is not
required, but it is courteous to inform your user about the "why." :)
2021-07-18 17:52:36 -05:00
Jaidyn Ann d05793bbf9 (purple) Add-on and protocol icons
Pidgin's icon has been borrowed as the add-on's icon― and protocol icons
are taken from `$DATA_DIR/pixmaps/Pidgin/protocol/`, just as
Pidgin/libpurple installs them.

Any third-party plugins will also install their icons there, even
if just locally.

I've updated the libpurple package to include these icons, hopefully
that'll get merged.
2021-07-07 15:05:49 -05:00
Jaidyn Ann 91c7e44b44 (purple) Register per-protocol commands 2021-07-05 23:56:59 -05:00
Jaidyn Ann c0f126206a Include default templates, split "room"
The "room" template has been split into two seperate
templates― "join_room" and "create_room". Before, "room" was used in the
room creation window, but now that's delegated to "create_room".

"join_room" is used with the join window― so now, the add-on has total
control over the slots used to join/create rooms generally, if they
specify the templates. Even a "/join" command could be overriden by the
add-on.

Also, default templates are now in use. Rather than add-ons being
required to specify templates, there are sensible defaults included with
Cardie for each one.
2021-07-05 13:48:33 -05:00
Jaidyn Ann ee8584e14c (purple) Fetch room template from purple 2021-07-04 11:31:32 -05:00
Jaidyn Ann 4d044144b3 (purple) Roster management
Fixes #28
2021-07-03 15:01:00 -05:00
Jaidyn Ann d883c23d18 Reorganize settings directory, custom purple paths
The settings file-hierarchy has been changed a bit:
	* Cardie/
		* preferences
		* Accounts/
		* Cache/
			* Accounts/
			* Add-Ons/

`Cardie/Protocols` is now `Cardie/Accounts`, and the cache directory
has been split into two. `Cache/Accounts/` is for account-specific
cached data (e.g., cached roster icons, data, etc.), and
`Cache/Protocols` is for protocol-wide settings/data.

For purple, this will be used as the user's libpurple directory,
which has been moved from the default of `~/.purple` (yikes!)

Some plugin search-paths have been given to purple, too― lib
directories + "/purple2/", and Cardie/Cache/Add-Ons/purple/plugins/.
2021-06-30 21:05:43 -05:00
Jaidyn Ann 30e3d6eefd (purple) Handle own status changes 2021-06-27 20:42:37 -05:00
Jaidyn Ann f755fa298b (purple) Disconnection of accounts, quit server w/o Cardie 2021-06-27 17:33:20 -05:00
Jaidyn Ann 588b32b9c3 (purple) Main loop, server→add-on→app communication
Now the purple add-on's starting to come together with a clear
structure:
	* Add-on sends IM_MESSAGES etc to the server for processing
	* Server sends all (reply/etc) messages to add-on, which sends
	  to app

It's worth noting that on the add-on's side, no looper or handler is
used for receiving messages, it's all through sending serialized
BMessages to the add-on's connect_thread buffer.

PurpleAccounts are now reliably associated with Cardie's account names
and the thread ID of their respective connect_thread.

The GLib main-loop is gone over regularly thanks to a message runner.

Now, the add-on can log into/create accounts, connect to them, and send
the IM_PROTOCOL_READY notification to Cardie as appropriate.
2021-06-27 16:46:38 -05:00
Jaidyn Ann 0aea480ec2 (purple) Loading Cardie-side account settings into PurpleAccount 2021-06-26 20:40:39 -05:00
Jaidyn Ann 6507a4182f Receive protocols' settings templates from libpurple 2021-06-24 12:22:34 -05:00
Jaidyn Ann ddaf39c300 Returning libpurple protocol amount and names
The libpurple add-on has been split into two parts― a background process
that will actually interface with libpurple, and an add-on that acts as
intermediary between Cardie and the process. This helps prevent
redundancy, and is giving me a lot less trouble that directly loading
libpurple.

The protocol amount and names are now returned by the add-on (through
protocol_count() and protocol_at() respectively)― you can see them in
Preferences' protocol list.
2021-06-23 23:57:27 -05:00
Jaidyn Ann b52be74dfb Init libpurple add-on 2021-06-22 14:42:07 -05:00