
This document describes the architectural changes in KMuddy, that will be done
after KMuddy 1.0 is out (though some of these might be implemented sooner).
It is by no means complete, and it's also a bit disorganized, so be careful ;)

Motivation
----------
Currently, all provided features are compiled into one big binary. Problem with
this approach is that classes that initialize all the features get more and more
bloated and more bugs may appear. Also, bigger structure is more difficult to
maintain, which leads into ad-hoc immplemented features, that get kinda lost in
all that mess. To prevent this from happening, a more distributed architecture
is planned. Here, only basic features shall be put into the core binary, everything
that's not necessary for core functionality of the program, will be moved out into
a plug-in. In addition, the core will be split into the executable and a separate
library, containing classes that can be used in plug-ins to integrate themselves into
KMuddy.

Plug-ins
--------
Plug-ins will also be allowed to put a new page into some dialogs, mainly application
settings and profile settings. They can also add new items into the menus.
More importantly, plug-ins will receive everything that comes from the MUD, and also
all commands being sent to the MUD, and they have a chance to modify it, before
the core processes it. In addition, plug-ins will be able to register for receiving
certain macros/functions (see KMuddy scripting language) and process those, extending
KMuddy's capabilities.

Sound plug-ins
--------------
Currently, support and SDL/aRts has to be determined at compile-time. This makes
creating binary packages a bit problematic. Thus, all sound system related stuff
shall be moved into separate plug-ins, loaded and called by the core when needed.

Basic structure
---------------
lib/ - classes that are shared by KMuddy core and plug-ins
lib/widgets - some commonly used widgets
kmuddy/ - the core functionality
kmuddy/dialogs - core dialogs :)
plugins/ - plug-ins

The lib/ directory contains classes that can be manipulated by plug-ins - displayer,
ANSI parser, status line, preferences and so on...

There must NOT be any dependencies on core in lib.

Classes in current version of KMuddy (0.6 + some plug-in support) and their
fate in the new version
---------------------------------------------------------------------------
BASE:
-----
cAction - core
cActionList - core
cAlias - lib
cAliasList - lib
cANSIParser - lib
cCmdProcessor - core
cConnection - core, cConnPrefs needs to be moved out into cSession*
cConnectionInfo - lib
cConnPrefs - yes, no longer owned by cConnection
cConsole - lib/widgets
cDownloader - lib, change to make it universal (not MSP-only)
cGlobalSettings - lib, modify so that options are exported via public API, use map<>
    to store settings (so that plug-ins can store their settings)
cGroup - lib
cGroupList - lib
cInputLine - lib/widgets
cMCCP - core
cMSP - core
cMultiLineInput - move to plugin
cPlugin - lib
cPluginManager - core
cProfiles - lib
cPrompt - ??? (core or lib/widgets)
cRunningList - move to plugin
cRunningScript - move to plugin
cSaveableField - lib, use map<> to save attributes
cSaveableList - lib, drop dependency on cConnection, use list<>
cScript - move to plugin
cScriptList - move to plugin
cSendCmd - lib, but drop dependency on textproc (use signal instead)
cSessionBase - lib
cSession - lib and core - split into two classes, one in core inheriting from one in
    lib, the class in lib manages the classes in lib
cShortcut - core
cShortcutList - core
cSoundPlayer - into sound plug-ins
cStatus - lib/widgets, drop cConnection dependency
cTabBar - lib/widgets, maybe give it some methods that are currently in KMuddy class
cTelnet - core
cTextProcessor - core
cTimer - move to plugin
cTimerList - move to plugin
cTranscript - move to plugin
cTrigger - lib - modify to drop all dependencies on core, if possible (non-trivial)
cTriggerList - lib - modify to drop all dependencies on core, if possible (non-trivial)
cUNIXSocket - move to plugin
cVariable - lib
cVariableList - lib
KMuddy - core; split into KMuddy, cSessionManager, maybe more

New widgets used by dialogs, all go to lib/widgets:
----------------------------
cListManager
  - manages a cSaveableList (move up/down, ...)
  - supports adding new buttons (Run!, ...)
  - cSaveableField must have virtual QString getDescription()=0; to make this work
cPathInput
  - input dir/file name (of certain type, starting path)
  - label, inputline and button (opens filedialog)
cGroupChooser
  - list of groups to choose from

DIALOGS (in kmuddy/dialogs, unless stated otherwise):
--------
cDirList - lib/widgets, use cPathInput
cNumberedListItem - lib/widgets
cNumberedCheckListItem - lib/widgets
dlgAliasTrigger - use cListManager
dlgAppSettings - <EXTENSIBLE by plugins>
dlgConnect - (no change)
dlgDumpBuffer - move to plugin, use cPathInput
dlgEditAction - (no change)
dlgEditAliasTrigger - use cPathInput and cGroupChooser
dlgEditProfile - (no change)
dlgEditScript - move to plugin
dlgEditShortcut - (no change)
dlgEditTimer - move to plugin
dlgEditVariable - move to plugin
dlgGrabKey - (no change)
dlgGroups - <maybe move functionality to cListManager?>
dlgImportExportProfile - use cPathInput
dlgIntNumInput - (no change)
dlgMultiline - move to plugin
dlgProfileSettings - <EXTENSIBLE by plugins>, use cPathInput
dlgQuickConnect - (no change)
dlgRunningList - move to plugin
dlgScripts - move to plugin, use cListManager
dlgShortcuts - use cListManager
dlgStatistics - <EXTENSIBLE by plugins>
dlgTimers - move to plugin, use cListManager
dlgTranscript - move to plugin, use cPathInput
dlgVariables - move to plugin, use cListManager


PLUG-INS
--------
The following plug-ins are to be considered base plug-ins - will be distributed
together with KMuddy, as they provide important functionality...

MULTILINE - multi-line edit (the separate one)
TRANSCRIPT - basic transcript
VARIABLES - GUI and macros for manipulating variables (the storage classes are in
  core)
COMMANDS - many useful commands (/disp, /sysmsg, /quit, /status, ...)
SCRIPTING - external scripting, variable server, /exec command

These plug-ins are not so important, they might be distributed with KMuddy or
separately, as determined later.

ADVTRANSCRIPT - advanced transcript (maybe merge with TRANSCRIPT?)
TIMERS - timer support, /rep
STATISTICS - connection statistics
COLORS - expand some sequences in user commands into ANSI color codes
VARTRIG - triggers reacting on variable changes
MXPTRIG - MXP-related stuff, special triggers mostly (MXP support is in core
    and libmxp)
MAPPER - the mapper
MATH - many math functions usable in expressions
STRINGS - functions/macros for string manipulation
FILES - functions/macros for file manipulation
DB - database support

Handling of lists and groups
----------------------------
- all objects organizable into groups
- some object groups need priorities, others don't
- each object belongs to exactly one group
- the list editor should be able to modify the groups
- cSaveableList should be modified so that it contains a list of groups, each of them
  containing a list of objects (i.e. list of lists)
- all that has to be loaded/saved
- each group and object should know how to disable itself
- list editor should have Enable/Disable button (or checkboxes near items or
  something), must be configurable (disabling a variable makes no sense)
- separate group-management should no longer be needed

Global/profile settings
-----------------------
Current way of having two methods per config option (get/set) is not very good.
We should use another approach - a couple of mappings, one for each option type
(int, bool, string, ...). When saving stuff, care should be taken not to mix two
valueswith equal name, but different type (could be done by prepending/appending
type-prefix/suffix to name, or by having one group per type). Everyone who wants
some config-option should also provide default value, returned if such option
hasn't been set yet.

Managing aliases/trgigers/groups via input-line
-----------------------------------------------
Macros should be provided to allow adding/modifying/deleting/(de)activating of stuff.
TODO: those macros

storing session-related data in plug-ins
----------------------------------------
method 1: map<cSession *, cDataStorage *> data; - for data that should not be saved
method 2: storing in cConnPrefs - if that data has to be remembered between sessions

saving lists/larger data/... in plug-ins (to a separate file)
-------------------------------------------------------------
cConnPrefs knows current profile name - add methods to return path where configfile
should be written.
Profile import/export has to be modified to support those files! (currently it
has a fixed list of files to export/import)

syncing dialogs
---------------
- lists should emit some signal, whenever a change occurs, so that dialogs can be
kept in sync (triggers can alter stuff with the new macros, even if the dialogs
are modal (so there's no reason to have those dlgs modal)

Triggers and scripting
----------------------
 SEE FORUMS :)

Events/actions
--------------
Many objects will be capable of registering themselves with an event/action
class. Here they will be allowed to publish method calls and register events
that they can trigger. Some plug-in wil then provide functions to call those
methods and also to call some commnad(s) when some event fires off.
Most things shall be based on these events - e.g. timers will be hooked to
some timeout event, alias/trigger processing will also be based on some event
(with help of the calling class - we need to set some flags about things like
gagging and so).
Some priorities for event handlers may need to be introduced.
There could be an entire module that would allow the user to hook their macros
on various events; it may also provide something like /invokeevent to allow
hooking on custom events (something like /notify for external scripts).

Custom commands and functions
-----------------------------
There will be some plug-in that will allow custom commands (similar to aliases,
but it'd be clear that these are custom commands and not MUD commands) and
functions (these can then be included in []-eval blocks).
Functions need to return some value.
The function is simply a list of expressions + possibility to assign result
of that expression to some variable (expressions can't do that natively due
to immediate variable expansion)
Some special variable holding result of last expression will also be useful.
Result of the very last expression of the function shall be the return value
of the whole function.
Recursive calls may also be allowed (LIMITED due to lack of local
variables).

Tags
----
- each object can have a tag (more tags?).
- you can export all objects with some tag(s) or import them, possibly renaming
each tag, or delete all existing objects with a given tag and import new ones,
or whatever you want.
- list of defined tags + some description...


