eol

git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/branches/ZeroRadiant@190 8a3a26a2-13c4-0310-b231-cf6edde360e5

docs/developer/data-driven-design.txt

@@ -1,76 +1,76 @@
-Listing of required modules and interfaces as an XML file
-=========================================================
-
-Purpose:
---------
-
-Make the editor more data driven. Be able to specify during
-startup the full running configuration of the editor:
-- what modules to load
-- general execution paths (i.e. what's in the project settings)
-- configuration for the loaded modules
-- user preferences
-
-Feature Requirements:
----------------------
-
-This is primarily intended for multiple games support. A restart
-of the editor may be required when going from one game to the
-other, but otherwise it should read the XML file and initialize
-the right modules and APIs from there.
-
-Don't have a clear view of what multiple games support is gonna
-be like. Can list a few things:
-
-- some interfaces are required for startup in a given game mode.
-That's primarily what the XML config file is there for.
-For instance in Q3 you will require Q3 map format module
-and Q1 will require Q1 map format module
-
-- some modules are to be ignored? that's primary intended to 
-avoid loading unneeded modules.
-
-- some plugins are loaded for all games?
-- some plugins are only relevant for some games?
-(those two suggest various installation paths for modules
-and directory-based scan?)
-
-- a plugin might require some other APIs to complete it's loading
-process (i.e. sending it's own XML description of required
-interfaces).
-
-Constaints:
------------
-
-We have a nasty collision between preferences / project settings
-and XML requirements. All three things need to be unified in some way.
-The long term target being to have a central installation location 
-for the editor, and independant packages for each game.
-
-What kind of difference is there between project settings and prefs?
-Prefs would be user settings that survive throughout all games, 
-whereas project settings are per-game / per-mod configuration. Turns
-out it's all a matter of loading the right configuration chunks at the
-right time.
-
-Proposed implementation:
-------------------------
-
-Use key/values (== property bags) based on XML format for everything.
-Use them on project settings, and user prefs. The only difference
-between what would be project settings and what would be user pref
-is in which game configuration they are loaded, and how they are used.
-
-Project templates: We have a particular syntax to build settings from 
-a 'template' version. Instead of loading a project template, we should
-be selecting a template from a list.
-
-Default startup: If we are configured to load last project on startup,
-load it .. otherwise display a list of games and templates?
-
-Module library:
----------------
-
-The dynamic loading / interfaces sharing / pure virtual classes needs
-to be implemented in a generic module. It should be the basis of the
-editor startup process.
+Listing of required modules and interfaces as an XML file
+=========================================================
+
+Purpose:
+--------
+
+Make the editor more data driven. Be able to specify during
+startup the full running configuration of the editor:
+- what modules to load
+- general execution paths (i.e. what's in the project settings)
+- configuration for the loaded modules
+- user preferences
+
+Feature Requirements:
+---------------------
+
+This is primarily intended for multiple games support. A restart
+of the editor may be required when going from one game to the
+other, but otherwise it should read the XML file and initialize
+the right modules and APIs from there.
+
+Don't have a clear view of what multiple games support is gonna
+be like. Can list a few things:
+
+- some interfaces are required for startup in a given game mode.
+That's primarily what the XML config file is there for.
+For instance in Q3 you will require Q3 map format module
+and Q1 will require Q1 map format module
+
+- some modules are to be ignored? that's primary intended to 
+avoid loading unneeded modules.
+
+- some plugins are loaded for all games?
+- some plugins are only relevant for some games?
+(those two suggest various installation paths for modules
+and directory-based scan?)
+
+- a plugin might require some other APIs to complete it's loading
+process (i.e. sending it's own XML description of required
+interfaces).
+
+Constaints:
+-----------
+
+We have a nasty collision between preferences / project settings
+and XML requirements. All three things need to be unified in some way.
+The long term target being to have a central installation location 
+for the editor, and independant packages for each game.
+
+What kind of difference is there between project settings and prefs?
+Prefs would be user settings that survive throughout all games, 
+whereas project settings are per-game / per-mod configuration. Turns
+out it's all a matter of loading the right configuration chunks at the
+right time.
+
+Proposed implementation:
+------------------------
+
+Use key/values (== property bags) based on XML format for everything.
+Use them on project settings, and user prefs. The only difference
+between what would be project settings and what would be user pref
+is in which game configuration they are loaded, and how they are used.
+
+Project templates: We have a particular syntax to build settings from 
+a 'template' version. Instead of loading a project template, we should
+be selecting a template from a list.
+
+Default startup: If we are configured to load last project on startup,
+load it .. otherwise display a list of games and templates?
+
+Module library:
+---------------
+
+The dynamic loading / interfaces sharing / pure virtual classes needs
+to be implemented in a generic module. It should be the basis of the
+editor startup process.