From 48a6d04aded516a8eead31b1e78544efb3b7e367 Mon Sep 17 00:00:00 2001 From: ailin-nemui Date: Mon, 11 Feb 2019 18:04:46 +0100 Subject: [PATCH] run syncdocs.sh --- docs/design.txt | 231 +++++++++++++++++++++++------------------------- 1 file changed, 110 insertions(+), 121 deletions(-) diff --git a/docs/design.txt b/docs/design.txt index 3f372829..6888f211 100644 --- a/docs/design.txt +++ b/docs/design.txt @@ -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 - \ / - 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 +(IRC, ICQ, xxx and yyy are chat protocols ..) +(sub1 and sub2 are submodules of IRC module, like DCC and flood protect) - (IRC, ICQ, xxx and yyy are chat protocols ..) - (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. +Signals - 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. +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 :) - ** 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 - 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 :) +signal_emit("mysignal", 1, "hello"); - 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: +Sends a “mysignal” function with one argument “hello” - before that, you should +have grabbed the signal somewhere else with: - 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 - should have grabbed the signal somewhere else with: +signal_add("mysignal", (SIGNAL_FUNC) sig_mysignal); - static void sig_mysignal(const char *arg1) - { - /* arg1 contains "hello" */ - } +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 +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 - specify if you want to grab the signal first, "normally" or last. You can - also stop the signal from going any further. +See src/core/signals.h for definition of the signal function, and signals.txt +for a list of signals. - 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. +lib-config - See src/core/signals.h for definition of the signal function, and - signals.txt for a list of signals. +Irssi depends on this for reading and saving configuration. (created by me for +irssi) +CORE module - ** lib-config +Provides some functionality that all other modules can use: - Irssi depends on this for reading and saving configuration. - (created by me for irssi) + • 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 - ** 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: - - 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 +GUI modules + • 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, ..) - - printtext() - parsing texts and feeding it for GUI to print. - - themes - - translation tables - - text hilighting - - command history - - user interface (/commands) for CORE's functionality + • 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 - ** 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