Commit Graph

7 Enmetoj

Author SHA1 Message Date
Jaidyn Ann 4d044144b3 (purple) Roster management
Fixes #28
2021-07-03 15:01:00 -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