aniani/irssi
1
0
Fork 0
mirror of https://github.com/irssi/irssi.git synced 2024-12-04 14:46:39 -05:00
Code

run syncdocs.sh

Browse Source
This commit is contained in:
ailin-nemui 2019-02-11 18:04:46 +01:00
parent 6239a8b791
commit 48a6d04ade
1 changed files with 110 additions and 121 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

231
docs/design.txt
View File

@ -1,150 +1,139 @@
Design
Irssi's hierarchy is something like this: Irssi’s hierarchy is something like this:
sub1 sub2
\ /
xxx IRC COMMON ICQ yyy
| | | | |
'----+-----:-----+----+----'
|
GUI (gtk/gnome, qt/kde, text, none)
|
sub1 sub2 |
\ / |
xxx IRC | COMMON ICQ yyy
'----+-----+-----+----+----'
|
COMMON UI
|
sub1 sub2 |
\ / |
xxx IRC | ICQ yyy
| | | | |
'----+-----+-----+----'
|
CORE
/
lib-config
sub1 sub2 (IRC, ICQ, xxx and yyy are chat protocols ..)
\ /
xxx IRC COMMON ICQ yyy
|____|___________|____|____|
|
GUI (gtk/gnome, qt/kde, text, none)
|
sub1 sub2 |
\ / |
xxx IRC | COMMON ICQ yyy
|____|_____|_____|____|____|
|
COMMON UI
|
sub1 sub2 |
\ / |
xxx IRC | ICQ yyy
|____|_____|_____|____|
|
CORE
/
lib-config
(sub1 and sub2 are submodules of IRC module, like DCC and flood protect)
(IRC, ICQ, xxx and yyy are chat protocols ..) Chat protocols and frontends are kept in separate modules. Common UI and GUI
(sub1 and sub2 are submodules of IRC module, like DCC and flood protect) 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
Chat protocols and frontends are kept in separate modules. Common UI Communication between different modules are done with “signals”. They are not
and GUI modules also have the common parts which don't know anything related to UNIX signals in any way, you could more like think of them as
about the chat protocols. This should allow implementing modules to “events” - which might be a better name for them, but I don’t really want to
whatever chat protocols and with whatever frontends easily. change it anymore :)
** Signals 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:
Communication between different modules are done with "signals". They are signal_emit("mysignal", 1, "hello");
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 :)
So, you send signal with signal_emit() and it's sent to all modules that Sends a “mysignal” function with one argument “hello” - before that, you should
have grabbed it by calling signal_add() in their init function. For have grabbed the signal somewhere else with:
example:
signal_emit("mysignal", 1, "hello"); static void sig_mysignal(const char *arg1)
{
/* arg1 contains "hello" */
}
Sends a "mysignal" function with one argument "hello" - before that, you signal_add("mysignal", (SIGNAL_FUNC) sig_mysignal);
should have grabbed the signal somewhere else with:
static void sig_mysignal(const char *arg1) There are three different signal_add() functions which you can use to specify
{ if you want to grab the signal first, “normally” or last. You can also stop the
/* arg1 contains "hello" */ signal from going any further.
}
signal_add("mysignal", (SIGNAL_FUNC) sig_mysignal); Emitting signal with it’s name creates a small overhead since it has to look up
the signal’s numeric ID first, after which it looks up the signal structure.
This is done because if you call a signal really often, it’s faster to find it
with it’s numeric ID instead of the string. You can use signal_get_uniq_id()
macro to convert the signal name into ID - you’ll have to do this only once! -
and use signal_emit_id() to emit the signal. Don’t bother to do this unless
your signal is sent (or could be sent) several times in a second.
There are three different signal_add() functions which you can use to See src/core/signals.h for definition of the signal function, and signals.txt
specify if you want to grab the signal first, "normally" or last. You can for a list of signals.
also stop the signal from going any further.
Emitting signal with it's name creates a small overhead since it has to lib-config
look up the signal's numeric ID first, after which it looks up the signal
structure. This is done because if you call a signal _really_ often,
it's faster to find it with it's numeric ID instead of the string. You
can use signal_get_uniq_id() macro to convert the signal name into ID -
you'll have to do this only once! - and use signal_emit_id() to emit the
signal. Don't bother to do this unless your signal is sent (or could be
sent) several times in a second.
See src/core/signals.h for definition of the signal function, and Irssi depends on this for reading and saving configuration. (created by me for
signals.txt for a list of signals. irssi)
CORE module
** lib-config Provides some functionality that all other modules can use:
Irssi depends on this for reading and saving configuration. • signal handling
(created by me for irssi) • 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
** CORE module • knows basics about windows and window items (=channels, queries, ..)
• printtext() - parsing texts and feeding it for GUI to print.
• themes
• translation tables
• text hilighting
• command history
• user interface (/commands) for CORE’s functionality
Provides some functionality that all other modules can use: GUI modules
- 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
• all the rest of the functionality needed for a working client.
** COMMON UI module IRC module
- knows basics about windows and window items (=channels, queries, ..) • CORE
- printtext() - parsing texts and feeding it for GUI to print. □ IRC specific /commands
- themes □ flood protecting commands sent to server
- translation tables □ creating IRC masks based on nick/address for bans, ignores, etc.
- text hilighting □ keeps list of channels, nicks, channel modes, bans, etc.
- command history □ keeps list of servers, server settings, irc networks, server
- user interface (/commands) for CORE's functionality 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
** GUI modules • placing channels and queries in windows
• nick completion
• printing infomation of some events
- 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 UI module
- placing channels and queries in windows
- nick completion
- printing infomation of some events