mirror of
https://github.com/irssi/irssi.git
synced 2024-12-04 14:46:39 -05:00
run syncdocs.sh
This commit is contained in:
ailin-nemui
parent
6239a8b791
commit
48a6d04ade
175
docs/design.txt
175
docs/design.txt
@ -1,25 +1,27 @@
|
|||||||
|
Design
|
||||||
|
|
||||||
Irssi's hierarchy is something like this:
|
Irssi’s hierarchy is something like this:
|
||||||
|
|
||||||
|
|
||||||
sub1 sub2
|
sub1 sub2
|
||||||
\ /
|
\ /
|
||||||
xxx IRC COMMON ICQ yyy
|
xxx IRC COMMON ICQ yyy
|
||||||
|____|___________|____|____|
|
| | | | |
|
||||||
|
'----+-----:-----+----+----'
|
||||||
|
|
|
|
||||||
GUI (gtk/gnome, qt/kde, text, none)
|
GUI (gtk/gnome, qt/kde, text, none)
|
||||||
|
|
|
|
||||||
sub1 sub2 |
|
sub1 sub2 |
|
||||||
\ / |
|
\ / |
|
||||||
xxx IRC | COMMON ICQ yyy
|
xxx IRC | COMMON ICQ yyy
|
||||||
|____|_____|_____|____|____|
|
'----+-----+-----+----+----'
|
||||||
|
|
|
|
||||||
COMMON UI
|
COMMON UI
|
||||||
|
|
|
|
||||||
sub1 sub2 |
|
sub1 sub2 |
|
||||||
\ / |
|
\ / |
|
||||||
xxx IRC | ICQ yyy
|
xxx IRC | ICQ yyy
|
||||||
|____|_____|_____|____|
|
| | | | |
|
||||||
|
'----+-----+-----+----'
|
||||||
|
|
|
|
||||||
CORE
|
CORE
|
||||||
/
|
/
|
||||||
@ -27,29 +29,28 @@
|
|||||||
|
|
||||||
|
|
||||||
(IRC, ICQ, xxx and yyy are chat protocols ..)
|
(IRC, ICQ, xxx and yyy are chat protocols ..)
|
||||||
|
|
||||||
(sub1 and sub2 are submodules of IRC module, like DCC and flood protect)
|
(sub1 and sub2 are submodules of IRC module, like DCC and flood protect)
|
||||||
|
|
||||||
|
Chat protocols and frontends are kept in separate modules. Common UI and GUI
|
||||||
|
modules also have the common parts which don’t know anything about the chat
|
||||||
|
protocols. This should allow implementing modules to whatever chat protocols
|
||||||
|
and with whatever frontends easily.
|
||||||
|
|
||||||
Chat protocols and frontends are kept in separate modules. Common UI
|
Signals
|
||||||
and GUI modules also have the common parts which don't know anything
|
|
||||||
about the chat protocols. This should allow implementing modules to
|
|
||||||
whatever chat protocols and with whatever frontends easily.
|
|
||||||
|
|
||||||
** Signals
|
Communication between different modules are done with “signals”. They are not
|
||||||
|
related to UNIX signals in any way, you could more like think of them as
|
||||||
|
“events” - which might be a better name for them, but I don’t really want to
|
||||||
|
change it anymore :)
|
||||||
|
|
||||||
Communication between different modules are done with "signals". They are
|
So, you send signal with signal_emit() and it’s sent to all modules that have
|
||||||
not related to UNIX signals in any way, you could more like think of them
|
grabbed it by calling signal_add() in their init function. For example:
|
||||||
as "events" - which might be a better name for them, but I don't really
|
|
||||||
want to change it anymore :)
|
|
||||||
|
|
||||||
So, you send signal with signal_emit() and it's sent to all modules that
|
|
||||||
have grabbed it by calling signal_add() in their init function. For
|
|
||||||
example:
|
|
||||||
|
|
||||||
signal_emit("mysignal", 1, "hello");
|
signal_emit("mysignal", 1, "hello");
|
||||||
|
|
||||||
Sends a "mysignal" function with one argument "hello" - before that, you
|
Sends a “mysignal” function with one argument “hello” - before that, you should
|
||||||
should have grabbed the signal somewhere else with:
|
have grabbed the signal somewhere else with:
|
||||||
|
|
||||||
static void sig_mysignal(const char *arg1)
|
static void sig_mysignal(const char *arg1)
|
||||||
{
|
{
|
||||||
@ -58,93 +59,81 @@
|
|||||||
|
|
||||||
signal_add("mysignal", (SIGNAL_FUNC) sig_mysignal);
|
signal_add("mysignal", (SIGNAL_FUNC) sig_mysignal);
|
||||||
|
|
||||||
There are three different signal_add() functions which you can use to
|
There are three different signal_add() functions which you can use to specify
|
||||||
specify if you want to grab the signal first, "normally" or last. You can
|
if you want to grab the signal first, “normally” or last. You can also stop the
|
||||||
also stop the signal from going any further.
|
signal from going any further.
|
||||||
|
|
||||||
Emitting signal with it's name creates a small overhead since it has to
|
Emitting signal with it’s name creates a small overhead since it has to look up
|
||||||
look up the signal's numeric ID first, after which it looks up the signal
|
the signal’s numeric ID first, after which it looks up the signal structure.
|
||||||
structure. This is done because if you call a signal _really_ often,
|
This is done because if you call a signal really often, it’s faster to find it
|
||||||
it's faster to find it with it's numeric ID instead of the string. You
|
with it’s numeric ID instead of the string. You can use signal_get_uniq_id()
|
||||||
can use signal_get_uniq_id() macro to convert the signal name into ID -
|
macro to convert the signal name into ID - you’ll have to do this only once! -
|
||||||
you'll have to do this only once! - and use signal_emit_id() to emit the
|
and use signal_emit_id() to emit the signal. Don’t bother to do this unless
|
||||||
signal. Don't bother to do this unless your signal is sent (or could be
|
your signal is sent (or could be sent) several times in a second.
|
||||||
sent) several times in a second.
|
|
||||||
|
|
||||||
See src/core/signals.h for definition of the signal function, and
|
See src/core/signals.h for definition of the signal function, and signals.txt
|
||||||
signals.txt for a list of signals.
|
for a list of signals.
|
||||||
|
|
||||||
|
lib-config
|
||||||
|
|
||||||
** lib-config
|
Irssi depends on this for reading and saving configuration. (created by me for
|
||||||
|
irssi)
|
||||||
|
|
||||||
Irssi depends on this for reading and saving configuration.
|
CORE module
|
||||||
(created by me for irssi)
|
|
||||||
|
|
||||||
|
|
||||||
** CORE module
|
|
||||||
|
|
||||||
Provides some functionality that all other modules can use:
|
Provides some functionality that all other modules can use:
|
||||||
- signal handling
|
|
||||||
- keeping list of settings
|
|
||||||
- keeping list of /commands
|
|
||||||
- keeping track of loaded modules
|
|
||||||
- networking functions (with nonblocking connects, IPv6 support)
|
|
||||||
- handles connecting to servers
|
|
||||||
- raw logging of server's input/output data
|
|
||||||
- /EVAL support
|
|
||||||
- fgets() like function line_split() without any maximum line limits
|
|
||||||
- command line parameter handling
|
|
||||||
- miscellaneous useful little functions
|
|
||||||
- handles logging
|
|
||||||
|
|
||||||
|
• signal handling
|
||||||
|
• keeping list of settings
|
||||||
|
• keeping list of /commands
|
||||||
|
• keeping track of loaded modules
|
||||||
|
• networking functions (with nonblocking connects, IPv6 support)
|
||||||
|
• handles connecting to servers
|
||||||
|
• raw logging of server’s input/output data
|
||||||
|
• /EVAL support
|
||||||
|
• fgets() like function line_split() without any maximum line limits
|
||||||
|
• command line parameter handling
|
||||||
|
• miscellaneous useful little functions
|
||||||
|
• handles logging
|
||||||
|
|
||||||
** COMMON UI module
|
COMMON UI module
|
||||||
|
|
||||||
- knows basics about windows and window items (=channels, queries, ..)
|
• knows basics about windows and window items (=channels, queries, ..)
|
||||||
- printtext() - parsing texts and feeding it for GUI to print.
|
• printtext() - parsing texts and feeding it for GUI to print.
|
||||||
- themes
|
• themes
|
||||||
- translation tables
|
• translation tables
|
||||||
- text hilighting
|
• text hilighting
|
||||||
- command history
|
• command history
|
||||||
- user interface (/commands) for CORE's functionality
|
• user interface (/commands) for CORE’s functionality
|
||||||
|
|
||||||
|
GUI modules
|
||||||
|
|
||||||
** GUI modules
|
• all the rest of the functionality needed for a working client.
|
||||||
|
|
||||||
- all the rest of the functionality needed for a working client.
|
IRC module
|
||||||
|
|
||||||
|
• CORE
|
||||||
|
□ IRC specific /commands
|
||||||
|
□ flood protecting commands sent to server
|
||||||
|
□ creating IRC masks based on nick/address for bans, ignores, etc.
|
||||||
|
□ keeps list of channels, nicks, channel modes, bans, etc.
|
||||||
|
□ keeps list of servers, server settings, irc networks, server
|
||||||
|
reconnections and irc network splits
|
||||||
|
□ redirection of commands’ replies
|
||||||
|
□ lag detection
|
||||||
|
□ ctcp support and flood protection
|
||||||
|
□ Handles ignoring people
|
||||||
|
• DCC
|
||||||
|
□ DCC chat, send and get
|
||||||
|
• FLOOD
|
||||||
|
□ detects private or channel flooding and sends “flood” signal
|
||||||
|
□ automatic ignoring when flooding
|
||||||
|
• NOTIFYLIST
|
||||||
|
□ handles notifylist
|
||||||
|
|
||||||
** IRC module
|
IRC UI module
|
||||||
|
|
||||||
* CORE
|
• placing channels and queries in windows
|
||||||
|
• nick completion
|
||||||
|
• printing infomation of some events
|
||||||
|
|
||||||
- IRC specific /commands
|
|
||||||
- flood protecting commands sent to server
|
|
||||||
- creating IRC masks based on nick/address for bans, ignores, etc.
|
|
||||||
- keeps list of channels, nicks, channel modes, bans, etc.
|
|
||||||
- keeps list of servers, server settings, irc networks,
|
|
||||||
server reconnections and irc network splits
|
|
||||||
- redirection of commands' replies
|
|
||||||
- lag detection
|
|
||||||
- ctcp support and flood protection
|
|
||||||
- Handles ignoring people
|
|
||||||
|
|
||||||
* DCC
|
|
||||||
|
|
||||||
- DCC chat, send and get
|
|
||||||
|
|
||||||
* FLOOD
|
|
||||||
|
|
||||||
- detects private or channel flooding and sends "flood" signal
|
|
||||||
- automatic ignoring when flooding
|
|
||||||
|
|
||||||
* NOTIFYLIST
|
|
||||||
|
|
||||||
- handles notifylist
|
|
||||||
|
|
||||||
|
|
||||||
** IRC UI module
|
|
||||||
|
|
||||||
- placing channels and queries in windows
|
|
||||||
- nick completion
|
|
||||||
- printing infomation of some events
|
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user