Replaces libinterface's ToolButton, a custom button that can display
a pop-up menu on click (along with a custom image). It didn't scale well
with different themes and font-sizes compared to BButtons― which
ToolButton is supposed to look like to begin with.
A BButton-derived class is used instead, so these buttons look more
in-place among other buttons.
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." :)
Explicit room-creation using protocol's own "room" template is now
supported.
Two new protocol API messages were added― IM_CREATE_ROOM and
IM_ROOM_CREATED, which are parallels to IM_CREATE_CHAT and
IM_CHAT_CREATED. Rather than the latter two, though, these are wholy
based on the "room" template― their slots are completely determined by
the protocol.
A generic "TemplateWindow" was created, which allows catch-all creation
of windows that leverage protocols' templates. It's used for the
room-creation window (Chat->New Room / Alt+N), for example.
At some point, it ideally should replace even the JoinRoom window, and
maybe others.
A nice templating system is used for account settings dialogues― the
required slots are specified by the protocol, and are reflected in the
settings dialogue.
To generalize this templating system (and eventually use elsewhere),
ProtocolSettings was split into two classes― ProtocolSettings and
ProtocolTemplate.
The CayaProtocol::SettingsTemplate() call was also edited to require a
string parameter, naming the specific template that should be returned.
"account" is used for the account settings dialogue, and other values
are TBA.
Accounts can now be temporarily disabled (in a Pidgin-like style)
through Preferences->Accounts. Work is still required to allow
enabling/re-enabling of accounts on-the-fly, and for keeping an
account's disabled state persistent.
Previously, all Conversations/Contacts/Users were stored in the Server,
each in their respective KeyMaps, identified solely by their
identifiers. This leads to the glaring problem of overlap― if the user
has multiple accounts, some users/rooms might be used or present in multiple
accounts at the same time.
Now, each accounts' Contacts, Conversations, and Users are stored in
its ProtocolLooper, making this overlap impossible. An oversight of only
allowing one user identifier to be stored (fMySelf) in Server was also fixed
this way.
This is the bulk of the work required for multi-account support― now,
the user can join the same XMPP room on two seperate accounts, and it
works perfectly.
CayaProtocolAddOn now has the convenience functions ProtoIcon(),
ProtoSignature(), and ProtoFriendlySignature(), for getting info from
its default protocol.
Now an add-on can contain multiple protocols, and the protocol API has
changed. An add-on must now export protocol_count() and protocol_at(),
with the latter replacing protocol(). protocol_count() returning the
amount of protocols in a given add-on, and protocol_at(i) giving a
new CayaProtocol* "at" the given index.
CayaProtocol has also been changed, adding Signature(),
FriendlySignature(), Icon(), Path(), and SetPath(). The reasoning is
that different protocols (even within a single add-on) will have
different signatures and icons, so this data should be accessible from
the protocol itself.
CayaProtocolAddOn now has CountProtocols() and ProtocolAt(i), allowing
the accessing of multiple protocols. A CayaProtocolAddOn can be given a
default protocol index in the constructor, whose protocol will be
returned with Protocol(). Version() was also moved from CayaProtocol to
CayaProtocolAddOn.
* Add General section in Preference/Behavior
* Don't prompt at quit option under General section
* Show confirmation dialog on quit (if enabled)
Misc
* Replace +/- in preferences Accounts with Add/Del
* Implement enabled ones
* Add canditate preferences
* Implement singleton-like preferences class CayaPreferences. These are working but they are not stored in file at closing
Jaidyn Ann
Ivan Gualandri
Barrett
barrett
plfiorini
urnenfeld