mirror of
https://github.com/profanity-im/profanity.git
synced 2024-12-04 14:46:46 -05:00
Added some code documentation, DESIGN
This commit is contained in:
parent
0e3f7ac006
commit
95dbb68b38
166
DESIGN
Normal file
166
DESIGN
Normal file
@ -0,0 +1,166 @@
|
|||||||
|
Responsibilities are generally seperated into modules.
|
||||||
|
|
||||||
|
profanity.c
|
||||||
|
===========
|
||||||
|
|
||||||
|
Contains initialisation, main loop, and shutdown functions.
|
||||||
|
|
||||||
|
Initialisation is loading preferences, initialising any libraries/files/data
|
||||||
|
structures used.
|
||||||
|
|
||||||
|
The main loop is where the work is done. It will keep checking for a new
|
||||||
|
character on the input, if there is one deals with it, if not, goes around the
|
||||||
|
loop again.
|
||||||
|
|
||||||
|
If the character was a newline, the input line is processed, the result of
|
||||||
|
processing profanity will either continue (TRUE) or stop (FALSE).
|
||||||
|
|
||||||
|
Shutting down just involves clearing up resources.
|
||||||
|
|
||||||
|
title_bar.c, windows.c, status_bar.c, input_win.c
|
||||||
|
=================================================
|
||||||
|
|
||||||
|
Represent the different windows in Ncurses.
|
||||||
|
|
||||||
|
----------------------------------------------
|
||||||
|
| TITLE_BAR |
|
||||||
|
----------------------------------------------
|
||||||
|
| |
|
||||||
|
| |
|
||||||
|
| WINDOWS |
|
||||||
|
| |
|
||||||
|
| |
|
||||||
|
----------------------------------------------
|
||||||
|
| STATUS_BAR |
|
||||||
|
----------------------------------------------
|
||||||
|
| INPUT_WIN |
|
||||||
|
----------------------------------------------
|
||||||
|
|
||||||
|
The interface to the UI is all through windows.h, all UI modules share this
|
||||||
|
header:
|
||||||
|
|
||||||
|
|
||||||
|
windows.h
|
||||||
|
|
|
||||||
|
|
|
||||||
|
--------------------------------------------------
|
||||||
|
| | | |
|
||||||
|
title_bar.c windows.c status_bar.c inp_win.c
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
So any calls to the UI are through windows.h
|
||||||
|
|
||||||
|
title_bar.c and status_bar.c are pretty trivial.
|
||||||
|
|
||||||
|
windows.c
|
||||||
|
---------
|
||||||
|
|
||||||
|
Contains a list of prof_win structs called _wins, which consist of:
|
||||||
|
|
||||||
|
from: A string, the name of the recipient for this chat window
|
||||||
|
win: An ncurses pad containing the chat
|
||||||
|
y_pos: The current position in the chat window
|
||||||
|
paged: Whether or not the pad has been paged (i.e not showing the end)
|
||||||
|
|
||||||
|
The console is _wins[0], and has a special 'from' value of "_cons".
|
||||||
|
|
||||||
|
This module contains things like a pointer to the console window, the index
|
||||||
|
of the current window being displayed, a dirty flag that indicated the current
|
||||||
|
windows should be updated next time around the loop.
|
||||||
|
|
||||||
|
inp_win.c
|
||||||
|
---------
|
||||||
|
|
||||||
|
Doesn't do much more than handle each character with inp_get_char(). Deals
|
||||||
|
with all special chars for editing the input, HOME, PAGE UP, UP, DOWN etc.
|
||||||
|
|
||||||
|
command.c
|
||||||
|
=========
|
||||||
|
|
||||||
|
When the main input loop gets a '\n', process_input() is called with the
|
||||||
|
line of input.
|
||||||
|
|
||||||
|
This is where each command/message is handled.
|
||||||
|
|
||||||
|
jabber.c
|
||||||
|
========
|
||||||
|
|
||||||
|
All interaction with libstrophe is done here. Contains a references to the
|
||||||
|
libstrophe objects, connection, context etc.
|
||||||
|
|
||||||
|
Functions ending 'handler' are callback handlers registered with libstrophe,
|
||||||
|
for incomming messages etc.
|
||||||
|
|
||||||
|
contact.c
|
||||||
|
=========
|
||||||
|
|
||||||
|
PContact represents a contact with:
|
||||||
|
|
||||||
|
name: The contact full JID, e.g. somecontact@server.org
|
||||||
|
show: "Online", "Away" etc
|
||||||
|
status: "I'm not here right now", "At lunch" etc
|
||||||
|
|
||||||
|
It's an opaque pointer so all access to a PContact is encapsulated in this
|
||||||
|
module.
|
||||||
|
|
||||||
|
contact_list.c
|
||||||
|
==============
|
||||||
|
|
||||||
|
Currently has two purposes.
|
||||||
|
|
||||||
|
Firstly stores a live list of online contacts. Live meaning jabber.c will
|
||||||
|
call contact_list_add() and contact_list_remove() as it gets presence
|
||||||
|
notifications.
|
||||||
|
|
||||||
|
Secondly it is used for autocompleting contact names when typing them, hence
|
||||||
|
it stores the contact in a PAutocomplete, described later.
|
||||||
|
|
||||||
|
history.c
|
||||||
|
=========
|
||||||
|
|
||||||
|
Stores a history of all input and allows navigating through it, bash style.
|
||||||
|
|
||||||
|
Uses PHistory object, described later.
|
||||||
|
|
||||||
|
preferences.c
|
||||||
|
=============
|
||||||
|
|
||||||
|
Deals with loading and setting preferences saved in ~/.profanity.
|
||||||
|
|
||||||
|
Also allows autocomplete of previous JIDs the use has logged in with
|
||||||
|
(stored in ~/.profanity) by storing them in a PAutocomplete.
|
||||||
|
|
||||||
|
common.c
|
||||||
|
========
|
||||||
|
|
||||||
|
Functions written where older versions of GLib does not have them.
|
||||||
|
|
||||||
|
util.c
|
||||||
|
======
|
||||||
|
|
||||||
|
Some util functions, should probably move to common.c.
|
||||||
|
|
||||||
|
log.c
|
||||||
|
=====
|
||||||
|
|
||||||
|
Stored a reference to the log file, and provides functions for writing to it.
|
||||||
|
|
||||||
|
Library like modules
|
||||||
|
====================
|
||||||
|
|
||||||
|
prof_history.c and prof_autocomplete.c implement a generic way to deal with
|
||||||
|
command history and command autocompletion respectively.
|
||||||
|
|
||||||
|
The rest of Profanity uses them indirectly, via history.c for example.
|
||||||
|
And they know nothing about Profanity (no includes).
|
||||||
|
|
||||||
|
These modules use opaque pointers so all access must be through functions
|
||||||
|
exposed in their headers.
|
||||||
|
|
||||||
|
The idea is that these modules could be included in other applications.
|
||||||
|
|
||||||
|
The "prof_" prefix is just because they were created whilst developing
|
||||||
|
Profanity.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue
Block a user