Commit Graph

196 Enmetoj

Author SHA1 Message Date
Jaidyn Ann 3516c64ffc (jabber) Localization, init catkeys 2021-07-18 22:25:38 -05:00
Jaidyn Ann 6875c3cb75 (purple) Localization, init catkeys 2021-07-18 21:51:38 -05:00
Jaidyn Ann 23e6f4ba5a (jabber) Add debug output 2021-07-18 20:03:42 -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 8d47983c47 (purple) Send errors to Cardie; IM_PROTOCOL_DISABLED
Connection errors are now sent to Cardie through an IM_ERROR message
(which appear in a BAlert), and an IM_PROTOCOL_DISABLED IM_MESSAGE is
sent to Cardie when the account is disabled/connection fails.
2021-07-18 13:54:31 -05:00
Jaidyn Ann d43d09b238 (purple) Default SSL dir, fix message users 2021-07-17 14:18:06 -05:00
Jaidyn Ann 0c8af4dd86 (purple) Chat-members leaving, receiving statuses 2021-07-15 16:41:22 -05:00
Jaidyn Ann 91ab9d8fb7 (purple) NotifyMessage dialog
First of the NotifyUiOps― not sure if the others are used for anything
useful in our use-case, I'll implement as I run into them.
2021-07-12 10:09:29 -05:00
Jaidyn Ann c5521ad9a3 (purple) RequestAction dialogs
First progress in support for purple's Request dialogs
2021-07-11 15:22:49 -05:00
Jaidyn Ann 437154310b Add debug mode 2021-07-10 09:31:31 -05:00
Jaidyn Ann 5217c282e2 (purple) Fix message receive 2021-07-09 11:53:16 -05:00
Jaidyn Ann f4df6d0d3b Typing auto-complete for usernames 2021-07-09 11:52:57 -05:00
Jaidyn Ann 988a4ebfb6 (purple) Handle user_id and user_name dichotomy
Fixes #29
2021-07-07 20:44:11 -05:00
Jaidyn Ann 4294993761 (purple) Fix rdef in Makefile 2021-07-07 15:49:48 -05:00
Jaidyn Ann 4b372238cc Build purple by default 2021-07-07 15:09:19 -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 f0f2375b09 (purple) Senderless messages are system messages 2021-07-06 14:27:14 -05:00
Jaidyn Ann 735dda4188 (purple) Remove mod perms, command warnings
Since moderation commands are implemented per-protocol in libpurple
(with no easy way to use with the catch-all IM_ROOM_BAN_PARTICIPANT
message and corresponding command), the PERM_BAN, PERM_KICK, and a
couple other moderative perms aren't afforded to the user, disabling
these non-functional options in the UI.

The commands can still be implemented by the libpurple plugin, though.
If they aren't, purple will complain with some error message.
2021-07-06 14:13:10 -05:00
Jaidyn Ann 9d8b35fc86 (purple) Send user-roles to Cardie
Fixes #24
2021-07-06 12:08:51 -05:00
Jaidyn Ann e88a8372dc (purple) Unescape XML entities 2021-07-06 02:09:18 -05:00
Jaidyn Ann 0c48cf514b (purple) Execute commands, report status
Fixes #25
2021-07-06 01:22:08 -05:00
Jaidyn Ann 0864ddae81 (purple) Reformat UI ops 2021-07-06 00:56:16 -05:00
Jaidyn Ann 91c7e44b44 (purple) Register per-protocol commands 2021-07-05 23:56:59 -05:00
Jaidyn Ann 95da508a38 (purple) Editing of buddy's alias 2021-07-05 17:48:32 -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 23bee9b0a6 (jabber) Remove obselete Facebook and GTalk versions 2021-07-05 13:14:50 -05:00
Jaidyn Ann 74dcf452c2 (purple) Creation/joining rooms using "room" template
Fixes #30
2021-07-05 12:42:41 -05:00
Jaidyn Ann ee8584e14c (purple) Fetch room template from purple 2021-07-04 11:31:32 -05:00
Jaidyn Ann b051cbed5a (purple) Creation of chats 2021-07-03 15:01:32 -05:00
Jaidyn Ann 4d044144b3 (purple) Roster management
Fixes #28
2021-07-03 15:01:00 -05:00
Jaidyn Ann a6c9569be2 (purple) Append ':' to settings names as appropriate 2021-07-02 13:47:47 -05:00
Jaidyn Ann 58e3d99af5 (purple) Typo fix 2021-07-02 10:24:34 -05:00
Jaidyn Ann b5b24939ea Set IRC/Purple passwords as 'secret' fields 2021-07-02 09:19:58 -05:00
Jaidyn Ann 2dc364ef55 (purple) Client-initiated joining and leaving rooms 2021-07-01 20:52:46 -05:00
Jaidyn Ann d63fe22afe (purple) Handle outgoing invites
Fixes #23
2021-07-01 20:18:10 -05:00
Jaidyn Ann 10003276cd (purple) Handle incoming invites 2021-07-01 19:49:39 -05:00
Jaidyn Ann 140a7f8834 (purple) Load server-side contacts 2021-07-01 18:34:56 -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 fb070e841a Store default commands/menu items in resources 2021-06-30 14:27:58 -05:00
Jaidyn Ann 301e22bcb3 (purple) IMs as rooms 2021-06-29 20:02:45 -05:00
Jaidyn Ann f0256babc1 (purple) Sending of room participants
Fixes #27
2021-06-29 15:20:27 -05:00
Jaidyn Ann 06b1df8882 (purple) Sending messages to chats 2021-06-28 12:51:50 -05:00
Jaidyn Ann 82cf946bc8 (purple) Joining rooms, receiving chat messages 2021-06-28 12:13:24 -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 66df891577 (purple) Support drop-down string/path menu settings 2021-06-26 21:37:47 -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
Jaidyn Ann de28bc8673 Match up nick with own user_id 2021-06-21 03:22:35 -05:00
Jaidyn Ann 31bc304c0b Enable IRC protocol 2021-06-21 03:06:15 -05:00
Jaidyn Ann 0c615b01fd Basic IRC connection/messaging/joining, etc. 2021-06-21 01:54:42 -05:00
Jaidyn Ann 57ecbd1cb3 Init IRC add-on 2021-06-20 22:17:24 -05:00
Jaidyn Ann fbe6e66743 Change class names 2021-06-20 12:44:20 -05:00
Jaidyn Ann b1920dad47 Move command/menu-item registration to call
Registration of custom chat commands and menu-items for protocols was
done by the IM_REGISTER_* messages, and is now done through direct calls
to the CayaProtocol object.

The new model for call/message for protocols is this: Temporary
information (chat messages, roster members, etc.) should be accessed
through messages. Relatively static data (protocol name, commands)
should be accessed through direct calls to the protocol object.
2021-06-20 01:24:34 -05:00
Jaidyn Ann d4f82dccc6 Removal of roster members
Now roster members can be deleted through the RosterEditWindow.

IM_CONTACT_LIST_REMOVED_CONTACT was renamed to
IM_CONTACT_LIST_CONTACT_REMOVED to fit style of other API messages.

Fixes #1.
2021-06-20 01:22:59 -05:00
Jaidyn Ann a21c8f7601 Editing of roster members
Roster members' can now be edited (through Roster->Edit Roster / CMD+R)

TemplateWindows can now be populated through sending any IM_MESSAGE to
it (it will assume the slots of the message correspond to the
template's).

IM_CONTACT_LIST_ADDED_CONTACT was removed (for redundancy), and
IM_CONTACT_LIST_EDIT_CONTACT was added.
2021-06-19 22:03:02 -05:00
Jaidyn Ann f4342d9310 Roster management, adding new contacts
The base for roster management (RosterEditWindow) has been made, and
adding new contacts works. Up next is contact removal and editing.

This leverages a new template (as defined in a protocol's
CayaProtocol::SettingsTemplate()), "roster," which should contain all
slots pertinent to editing/adding a contact member.

Two new API messages were added for this― IM_CONTACT_LIST_CONTACT_ADDED
and IM_CONTACT_LIST_CONTACT_REMOVED. The former will functionally just
be IM_CONTACT_INFO, but with some semantical meaning.

A new CayaMessage (CAYA_EDIT_ROSTER) was also added.

TemplateWindow was also edited to this end: Now, like RosterWindow/View,
it can be given a specific accounts' instance id, and it will prevent
the selection of another account. A new constructor was also added, to
allow a ProtocolTemplate to be explicitly passed to it― probably from
the program itself.
2021-06-19 18:25:58 -05:00
Jaidyn Ann 84eb2d68ba Slight template window tweaks 2021-06-18 14:18:45 -05:00
Jaidyn Ann 4f8aaf7957 Add 'error' slot for templates 2021-06-18 12:49:30 -05:00
Jaidyn Ann 48f84377fc Room-creation for XMPP 2021-06-18 01:30:59 -05:00
Jaidyn Ann 3fbe072d42 Generalize protocol settings' GUI templating
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.
2021-06-17 17:02:29 -05:00
Jaidyn Ann 9eaeac24e6 Split icons into seperate RDEF files 2021-06-17 11:49:42 -05:00
Jaidyn Ann 8a9cb9effd Register commands & pop-up items through messages
Use IM_MESSAGEs, IM_REGISTER_COMMAND and IM_REGISTER_USER_ITEM, for
registering commands and user-list pop-up items.

The former replaces CayaProtocol::Commands(), which was a real bad idea
in the first place. Just awful. No idea why I did that instead of this,
which is nicer and significantly easier anyway.
2021-06-15 23:29:38 -05:00
Jaidyn Ann 83e98bd5a8 Remove obselete CayaProtocol::SaveLogs(), add ::Commands()
With the new use of RoomFlags for signifying whether or not a room's
chat should be populated with local logs (ROOM_POPULATE_LOGS),
SaveLogs() is redundant.

A Commands() method was added to the CayaProtocol class returning a
CommandMap, which will be used by Caya when searching for commands.

KeyList::AddList() and List::AddList() were also added to libsupport,
for convenience.
2021-06-15 14:40:28 -05:00
Jaidyn Ann b2489a5551 Cache roomflags, autojoin/autocreate based on them
Fixes #3
2021-06-13 02:35:16 -05:00
Jaidyn Ann 7c9d1d9eaa Rework communication of room metadata, add room flags
In the API, a firm distinction between initially fetching a room's
metadata and receiving further changes has been made:
IM_ROOM_METADATA will be sent to Caya on request (IM_GET_ROOM_METADATA)
with the room's name, subject, etc. The other metadata-related messages
should only be sent to Caya after the room is initialized, not as a
means of initially setting its metadata.

Basic room flags were added, though they aren't yet used― they should
allow the protocol/add-on/user to configure some room features. Logging,
auto-joining, etc.
2021-06-13 01:16:30 -05:00
Jaidyn Ann 9cd4ce18e1 Disable some menu items when no account is active
When no accounts are active, all items in the Menubar->Chat menu are
disabled, and some other menu items related to starting/managing chats
are disabled in other views.

One new message was added to the API― IM_PROTOCOL_READY, which tells
Caya that a given protocol has logged in and is ready to receive
messages (rather than just sending).

This is currently done in XMPP after the roster is loaded, which be a
process that stalls the protocol for a few seconds. IM_PROTOCOL_READY
should only be sent after those initial, potentially time-heavy
operations.
2021-06-12 16:13:52 -05:00
Jaidyn Ann dcc5e443d3 Support temporary disabling of accounts
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.
2021-06-11 20:33:28 -05:00
Jaidyn Ann 7767995400 Use account-based rather than protocol-based cache paths 2021-06-09 11:40:27 -05:00
Jaidyn Ann 5723f55433 Support sending invitations
Fixes #5
2021-06-08 21:43:41 -05:00
Jaidyn Ann 3827787d38 Jabber support for receiving invitations 2021-06-08 19:59:22 -05:00
Jaidyn Ann 26e99477fc Document protocol API 2021-06-07 11:45:30 -05:00
Jaidyn Ann 77d914312c Show users' joins/parts in chat view
New API messages were added to distinguish between a user leaving of
their own volition and being kicked/banned.

Messages are now shown in the chat view when a user leaves or or
kicked/banned, etc.
2021-06-07 00:03:15 -05:00
Jaidyn Ann 260b36012e Support moderation (muting, kicking, etc)
Allow kicking/banning/muting/unmuting/deafening and undeafening through
the UserListView right-click menu (if permissions are sufficient).

Support for banning, kicking, and muting were added to the XMPP add-on―
deafening isn't supported, so is left out.
2021-06-06 17:51:22 -05:00
Jaidyn Ann dc3fdd65c8 Store chatlogs in binary and text formats
If chat logs are stored in an endless plain-text file, they're going to be a
pain to parse. If they're stored in a binary file, they're a pain for
the user to `grep` or go through manually, but they're easier to parse.

Why not both?

Logs are now stored with a BMessage (with BStringLists) in the 'logs'
attribute, and the plain-text logs in the file itself.

The attribute will only store 20 messages, but the file itself will be
appended to forever.

The logs directory also changed, from ~/config/settings/Caya/Cache/Logs
to ~/config/settings/Caya/Logs.

Useful functions for reading/writing messages to and from an attribute were
borrowed from BePodder's libfunky. :-)
2021-06-06 12:02:26 -05:00
Jaidyn Ann fe99f3d83a Show moderation items in right-click user menu, by perm 2021-06-06 01:49:11 -05:00
Jaidyn Ann 6e1ca87890 Support for "Roles" (user, moderator, admin, etc.)
Add scaffodling support for arbitrary roles and permission-based (and
varying!) UI.

A new class, Role, represents a user's role in a given room, with three
values:
	* The role's title
	* The role's permission-set
	* The role's priority

The permission set is a bitmask value for various permissions (e.g.,
PERM_WRITE, PERM_BAN, etc), and priority is position in the hierarchy.
A user with higher priority (and PERM_BAN) can ban a user with lower
priority, but not vice-versa. Two users with the same priority can't
ban/kick/mute each other, etc.

These permissions should be used to determine what UI elements are
displayed― if the user doesn't have permission to ban users, then a
"Ban" button shouldn't exist. If the user is muted, they shouldn't be
able to type. So on and so forth.

For now, permissions are sent with a IM_ROLECHANGE message and stored
by the Conversation, but aren't really in use yet.

This system should be flexible groundwork to account for the varying
administrative hierarchies and norms of different protocols.
2021-06-06 00:59:07 -05:00
Jaidyn Ann 2f1aee3220 XMPP support for IM_ROOM_LEAVE/IM_ROOM_LEFT 2021-06-04 16:34:25 -05:00
Jaidyn Ann 89905fe23c Show/receive room subjects, show protocol icon in conversation view
The conversation view now displays the protocol icon and room subject.
Messages for receiving room names (IM_ROOM_NAME) and subjects
(IM_ROOM_SUBJECT) were added, and support for the latter was given to
the XMPP add-on.

New message APIs were added, and several (room-related) im_what values were
moved into the 150s/160s.

UserItem::_TintColor() was moved to CayaUtils, because it can be used in
several different contexts.
2021-06-04 13:57:04 -05:00
Jaidyn Ann 2e1190ae8d Fix handling of chat IDs
Don't show status notifications in group chats, make sure chat IDs are
found and set properly (on the XMPP side of things).
2021-06-03 20:24:34 -05:00
Jaidyn Ann a89bec40a3 Sending messages to MUCs, proper logging 2021-06-03 14:25:51 -05:00
Jaidyn Ann b66ea722b0 Send MUC participants on join, and send participants' status 2021-06-02 16:58:29 -05:00
Jaidyn Ann 061489ba2e Recieve messages from MUC rooms 2021-06-02 12:34:00 -05:00
Jaidyn Ann 770f7eaee3 Support for joining MUCs; Stanza error-handling
Adds basic support for joining MUCs― so basic that Caya won't even tell
the user they've joined, and messages can't be received.

The scaffolding for further MUC development was added, and some
much-needed error-handling for stanzas has been created.
2021-06-01 21:53:50 -05:00
Jaidyn Ann 0326cee687 Move roster into its own generic window
The roster list is now split from MainWindow into RosterWindow, which
can be used arbitrarily for selecting something from contacts. The
im_what, title, and target can be specified.

Right now it's in use under the Chat menu, "New chat…". Chats can only
have two members (DM/PM), so "New chat…" directly leads to the roster
list.

In the future, roster list might be extended to allow specification of
non-contact users based on their identifiers, or filtering based on
protocol/account― this could help it with "invites" to future rooms,
etc.

IM_CREATE_CHAT and IM_CHAT_CREATED were also added to the protocol API,
allowing a new chat to be explicitly created from Caya or the protocol.
2021-05-26 07:48:25 -05:00
Jaidyn Ann 3d020c4628 Populate conversations with logs, if any saved
Also adds a function to protocols to toggle this― if CayaProtocol::SaveLogs()
returns true, then local logs will be used to popualte conversation
windows. Otherwise, it's up to the protocol itself.

A new protocol IM_MESSAGE was also created, IM_LOGS_RECEIVED, which can
be used to populate conversations with old logs.
2021-05-24 19:12:42 -05:00
Jaidyn Ann 48d0b7bc96 Create Conversation class, use it instead of Contact for chats
This is a commit with it's foot in a lot of places, but:

The Conversation class was created as the abstraction of chats: All
ImMessages that are relevant to a conversation get routed through it,
meta-data on chats is stored in it (even if right now that's basically
limited to the user list and ID).

Server was given more methods to help accessing contacts―
ContactById(BString) and AddContact(Contact*). This better allows
Conversations to add and fetch Contacts as necessary. Right now, all
users in chats are treated as Contacts, so in the future creating an
independent userlist for Server (fUserMap?) would be useful.

Server also now stores all Conversations (fChatMap) and has some
convenience methods like for Contacts: Conversations(),
ConversationById(BString), and AddConversation(Conversation*).

CayaRenderView has been changed to not store user nicks, and will use
the appropriate nick of any arbitrarily-numbered user.

Users also have a map of all Conversations they are a part of
(fChatMap).

The Remove* methods of KeyMap now return the removed item.
2021-05-24 01:47:21 -05:00
Jaidyn Ann 61a1f0baf1 Allow multiple protocols per add-on
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.
2021-05-21 13:47:14 -05:00
Jaidyn Ann 53fe03d2c8 Generate protocols' settings templates by call 2021-05-20 09:32:52 -05:00
Jaidyn Ann 96195039e0 Use gloox'es jidJID() instead of deprecated jid() 2021-05-19 16:13:24 -05:00
Jaidyn Ann df55e1d9f5 Switch from Jam to Make 2021-05-19 16:12:19 -05:00
Jaidyn Ann c6c1bb349a Remove obselete libraries/protocols 2021-05-19 15:48:07 -05:00
Jérôme Duval ba991ee13c remove msn from the build 2017-01-30 07:22:31 +01:00
Dario Casalinuovo 6de2682326 MSNP: Fix bad return value 2015-07-21 03:00:28 +02:00
barrett17 007d2bda0a Initial rework of the build system to support the latest Haiku changes. Patch from Adrien Destgues included, Thanks! 2013-10-12 17:59:00 +00:00
Barrett 00440a3ffc Initial gcc2 support, patch from Haikuports, with a little modification by myself. Set the deskbar replicant show as default, and removed the gcc4 notice from preferences. 2013-07-31 22:34:52 +02:00
Barrett 830f1216f5 Merging caya and caya-gpl-protocols 2013-07-29 16:58:19 +02:00