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