jadedctrl/Chat-O-Matic
jadedctrl/ Chat-O-Matic
1
0
Disbranĉigi 0
Fontkodo Issues 20 Tirpetoj Actions Packages Projects Eldonoj 2 Wiki Activity
Chat-O-Matic/application/Makefile

202 lines
7.3 KiB
Makefile
Raw Normal View History

Switch from Jam to Make
2021-05-19 16:12:19 -05:00
## Haiku Generic Makefile v2.6 ##
## Fill in this file to specify the project being created, and the referenced
## Makefile-Engine will do all of the hard work for you. This handles any
## architecture of Haiku.
##
## For more information, see:
## file:///system/develop/documentation/makefile-engine.html
# The name of the binary.
Rename Caya to Cardie
2021-06-22 01:06:00 -05:00
NAME = Cardie
Switch from Jam to Make
2021-05-19 16:12:19 -05:00
# The type of binary, must be one of:
# APP: Application
# SHARED: Shared library or add-on
# STATIC: Static library archive
# DRIVER: Kernel driver
TYPE = APP
# If you plan to use localization, specify the application's MIME signature.
Rename Caya to Cardie
2021-06-22 01:06:00 -05:00
APP_MIME_SIG = application/x-vnd.cardie
Switch from Jam to Make
2021-05-19 16:12:19 -05:00
# The following lines tell Pe and Eddie where the SRCS, RDEFS, and RSRCS are
# so that Pe and Eddie can fill them in for you.
#%{
# @src->@
# Specify the source files to use. Full paths or paths relative to the
# Makefile can be included. All files, regardless of directory, will have
# their object files created in the common object directory. Note that this
# means this Makefile will not work correctly if two source files with the
# same name (source.c or source.cpp) are included from different directories.
# Also note that spaces in folder names do not work well with this Makefile.
SRCS = \
application/Account.cpp \
application/AccountManager.cpp \
Change class names
2021-06-20 12:44:20 -05:00
application/ChatProtocolAddOn.cpp \
Basic command storage and parsing A new class was added (ChatCommand) to represent commands, which are all stored in the Server iself. A command can be assigned any arbitrary BMessage, and can be given arguments with some semantic meaning (so far just "string" or "room participant," etc). "invite" and moderation commands were added (ban/kick/mute etc).
2021-06-15 00:19:52 -05:00
application/ChatCommand.cpp \
Rename ContactLinker to Contact
2021-05-23 14:39:07 -05:00
application/Contact.cpp \
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
application/Conversation.cpp \
Basis for custom userlist pop-up menu items
2021-06-15 21:05:21 -05:00
application/DefaultItems.cpp \
Switch from Jam to Make
2021-05-19 16:12:19 -05:00
application/EditingFilter.cpp \
application/ImageCache.cpp \
application/Main.cpp \
application/Notifier.cpp \
application/ProtocolLooper.cpp \
application/ProtocolManager.cpp \
application/ProtocolSettings.cpp \
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 16:51:37 -05:00
application/ProtocolTemplate.cpp \
Switch from Jam to Make
2021-05-19 16:12:19 -05:00
application/Server.cpp \
application/TheApp.cpp \
Split 'Contact' class into two This dichotomy is useful and necessary in multi-user chats, so I split Contact into a parent class, User. User should be used for generic members of rooms, Contact used mainly with the roster.
2021-05-23 15:10:14 -05:00
application/User.cpp \
Change class names
2021-06-20 12:44:20 -05:00
application/Utils.cpp \
Switch from Jam to Make
2021-05-19 16:12:19 -05:00
application/preferences/AccountDialog.cpp \
application/preferences/AccountListItem.cpp \
Change class names
2021-06-20 12:44:20 -05:00
application/preferences/AppPreferences.cpp \
Move window files to application/windows
2021-06-08 20:42:20 -05:00
application/preferences/PreferencesChatWindow.cpp \
Switch from Jam to Make
2021-05-19 16:12:19 -05:00
application/preferences/PreferencesAccounts.cpp \
application/preferences/PreferencesBehavior.cpp \
application/preferences/PreferencesReplicant.cpp \
Change class names
2021-06-20 12:44:20 -05:00
application/views/RenderView.cpp \
Group rooms in roomlist by account The ConversationListView is now an BOutlineListView, and rooms are added as subitems to the item of their associated account. Right now, account items aren't selectable or useful.
2021-06-11 17:24:04 -05:00
application/views/ConversationAccountItem.cpp \
Write conversation list, put it in main window Now all active conversations will be listed in the main window, in a ConversationListView. Clicking one of the items will open its conversation window as you'd expect, etc.
2021-05-27 11:15:30 -05:00
application/views/ConversationItem.cpp \
application/views/ConversationListView.cpp \
Move bulk of chat window into a dedicated ConvesationView This will help to move to a single-window layout, instead of having a dedicated window per-chat.
2021-05-28 08:38:33 -05:00
application/views/ConversationView.cpp \
Receive room invitations, allow user to accept or deny A BAlert is used to inform the user of room invitations― InviteDialogue― and to send their response directly to the protocol's looper. Some new protocol messages were added (and older ones were moved around to compenstate)― IM_ROOM_SEND_INVITE, IM_ROOM_INVITE_REFUSED, IM_ROOM_INVITE_RECEIVED, IM_ROOM_INVITE_ACCEPT, and IM_ROOM_INVITE_REFUSE.
2021-06-08 15:32:04 -05:00
application/views/InviteDialogue.cpp \
Switch from Jam to Make
2021-05-19 16:12:19 -05:00
application/views/NicknameTextControl.cpp \
Write conversation list, put it in main window Now all active conversations will be listed in the main window, in a ConversationListView. Clicking one of the items will open its conversation window as you'd expect, etc.
2021-05-27 11:15:30 -05:00
application/views/ReplicantStatusView.cpp \
application/views/ReplicantMenuItem.cpp \
Switch from Jam to Make
2021-05-19 16:12:19 -05:00
application/views/RosterItem.cpp \
application/views/RosterListView.cpp \
Split RosterWindow into per-account RosterView Most of RosterWindow's special functions have been split into a special BGroupView (including both the roster search-box and roster list), RosterView. This will give some more flexibility in other uses of the roster list. In addition, RosterViews can be tied to a specific account by its looper's instance ID, allowing it to either show all contacts (globally; if the ID is set to -1) or only those of the specified account. This can be useful, for example, when inviting contacts to a room― you can only invite contacts that use the same protocol, and are associated with your account, so showing all contacts doesn't make sense. The SearchBarTextControl class was removed, as it isn't particularly necessary.
2021-06-18 16:41:09 -05:00
application/views/RosterView.cpp \
Switch from Jam to Make
2021-05-19 16:12:19 -05:00
application/views/StatusMenuItem.cpp \
application/views/StatusView.cpp \
Room creation window; Catch-all template window 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.
2021-06-18 01:13:02 -05:00
application/views/TemplateView.cpp \
Add user-list to the conversation view, menu tweaks UserListView and UserItem were added as the backbone of the user-list, and the (currently unused) Caya message CAYA_SEND_INVITE was established for inviting users to rooms. Some menus were reworked (e.g., pop-ups of the RosterListView) or generally tweaked to be more sensical or consistent.
2021-05-31 10:50:43 -05:00
application/views/UserItem.cpp \
application/views/UserListView.cpp \
Move window files to application/windows
2021-06-08 20:42:20 -05:00
application/views/UserPopUp.cpp \
application/windows/AboutWindow.cpp \
application/windows/MainWindow.cpp \
Explicitly tie Conversations, Contacts, and Users to their ProtocolLoopers 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.
2021-06-10 15:16:43 -05:00
application/windows/PreferencesWindow.cpp \
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
application/windows/RosterEditWindow.cpp \
Move window files to application/windows
2021-06-08 20:42:20 -05:00
application/windows/RosterWindow.cpp \
Room creation window; Catch-all template window 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.
2021-06-18 01:13:02 -05:00
application/windows/TemplateWindow.cpp \
Move window files to application/windows
2021-06-08 20:42:20 -05:00
application/windows/UserInfoWindow.cpp
Switch from Jam to Make
2021-05-19 16:12:19 -05:00
# Specify the resource definition files to use. Full or relative paths can be
# used.
Rename Caya to Cardie
2021-06-22 01:06:00 -05:00
RDEFS = Cardie.rdef \
Split icons into seperate RDEF files
2021-06-17 11:49:42 -05:00
data/icons/status/Away.rdef \
data/icons/status/Busy.rdef \
data/icons/status/Offline.rdef \
data/icons/status/Online.rdef \
data/icons/replicant/Away.rdef \
data/icons/replicant/Busy.rdef \
Remove Caya icons
2021-06-20 11:44:16 -05:00
data/icons/replicant/Icon.rdef \
Split icons into seperate RDEF files
2021-06-17 11:49:42 -05:00
data/icons/replicant/ExitMenu.rdef \
data/icons/replicant/MessageReceived.rdef \
data/icons/replicant/Offline.rdef \
data/icons/replicant/Online.rdef \
data/icons/misc/Person.rdef \
data/icons/misc/Search.rdef \
data/icons/misc/Tool.rdef
Switch from Jam to Make
2021-05-19 16:12:19 -05:00
# Specify the resource files to use. Full or relative paths can be used.
# Both RDEFS and RSRCS can be utilized in the same Makefile.
RSRCS =
# End Pe/Eddie support.
# @<-src@
#%}
# Specify libraries to link against.
# There are two acceptable forms of library specifications:
# - if your library follows the naming pattern of libXXX.so or libXXX.a,
# you can simply specify XXX for the library. (e.g. the entry for
# "libtracker.so" would be "tracker")
#
# - for GCC-independent linking of standard C++ libraries, you can use
# $(STDCPPLIBS) instead of the raw "stdc++[.r4] [supc++]" library names.
#
# - if your library does not follow the standard library naming scheme,
# you need to specify the path to the library and it's name.
# (e.g. for mylib.a, specify "mylib.a" or "path/mylib.a")
LIBS = be expat interface runview shared support translation $(STDCPPLIBS)
# Specify additional paths to directories following the standard libXXX.so
# or libXXX.a naming scheme. You can specify full paths or paths relative
# to the Makefile. The paths included are not parsed recursively, so
# include all of the paths where libraries must be found. Directories where
# source files were specified are automatically included.
LIBPATHS =
# Additional paths to look for system headers. These use the form
# "#include <header>". Directories that contain the files in SRCS are
# NOT auto-included here.
SYSTEM_INCLUDE_PATHS = libs/
# Additional paths paths to look for local headers. These use the form
# #include "header". Directories that contain the files in SRCS are
# automatically included.
LOCAL_INCLUDE_PATHS =
# Specify the level of optimization that you want. Specify either NONE (O0),
# SOME (O1), FULL (O3), or leave blank (for the default optimization level).
OPTIMIZE :=
# Specify the codes for languages you are going to support in this
# application. The default "en" one must be provided too. "make catkeys"
# will recreate only the "locales/en.catkeys" file. Use it as a template
# for creating catkeys for other languages. All localization files must be
# placed in the "locales" subdirectory.
LOCALES =
# Specify all the preprocessor symbols to be defined. The symbols will not
# have their values set automatically; you must supply the value (if any) to
# use. For example, setting DEFINES to "DEBUG=1" will cause the compiler
# option "-DDEBUG=1" to be used. Setting DEFINES to "DEBUG" would pass
# "-DDEBUG" on the compiler's command line.
DEFINES :=
# Specify the warning level. Either NONE (suppress all warnings),
# ALL (enable all warnings), or leave blank (enable default warnings).
WARNINGS =
# With image symbols, stack crawls in the debugger are meaningful.
# If set to "TRUE", symbols will be created.
SYMBOLS :=
# Includes debug information, which allows the binary to be debugged easily.
# If set to "TRUE", debug info will be created.
DEBUGGER :=
# Specify any additional compiler flags to be used.
COMPILER_FLAGS =
# Specify any additional linker flags to be used.
LINKER_FLAGS =
# Specify the version of this binary. Example:
# -app 3 4 0 d 0 -short 340 -long "340 "`echo -n -e '\302\251'`"1999 GNU GPL"
# This may also be specified in a resource.
APP_VERSION :=
# (Only used when "TYPE" is "DRIVER"). Specify the desired driver install
# location in the /dev hierarchy. Example:
# DRIVER_PATH = video/usb
# will instruct the "driverinstall" rule to place a symlink to your driver's
# binary in ~/add-ons/kernel/drivers/dev/video/usb, so that your driver will
# appear at /dev/video/usb when loaded. The default is "misc".
DRIVER_PATH =
## Include the Makefile-Engine
DEVEL_DIRECTORY := /boot/system/develop/
include $(DEVEL_DIRECTORY)/etc/makefile-engine
include Makefile.common
CC = g++