docs/developer/data-driven-design.txt

   1 Listing of required modules and interfaces as an XML file\r
   2 =========================================================\r
   3 \r
   4 Purpose:\r
   5 --------\r
   6 \r
   7 Make the editor more data driven. Be able to specify during\r
   8 startup the full running configuration of the editor:\r
   9 - what modules to load\r
  10 - general execution paths (i.e. what's in the project settings)\r
  11 - configuration for the loaded modules\r
  12 - user preferences\r
  13 \r
  14 Feature Requirements:\r
  15 ---------------------\r
  16 \r
  17 This is primarily intended for multiple games support. A restart\r
  18 of the editor may be required when going from one game to the\r
  19 other, but otherwise it should read the XML file and initialize\r
  20 the right modules and APIs from there.\r
  21 \r
  22 Don't have a clear view of what multiple games support is gonna\r
  23 be like. Can list a few things:\r
  24 \r
  25 - some interfaces are required for startup in a given game mode.\r
  26 That's primarily what the XML config file is there for.\r
  27 For instance in Q3 you will require Q3 map format module\r
  28 and Q1 will require Q1 map format module\r
  29 \r
  30 - some modules are to be ignored? that's primary intended to \r
  31 avoid loading unneeded modules.\r
  32 \r
  33 - some plugins are loaded for all games?\r
  34 - some plugins are only relevant for some games?\r
  35 (those two suggest various installation paths for modules\r
  36 and directory-based scan?)\r
  37 \r
  38 - a plugin might require some other APIs to complete it's loading\r
  39 process (i.e. sending it's own XML description of required\r
  40 interfaces).\r
  41 \r
  42 Constaints:\r
  43 -----------\r
  44 \r
  45 We have a nasty collision between preferences / project settings\r
  46 and XML requirements. All three things need to be unified in some way.\r
  47 The long term target being to have a central installation location \r
  48 for the editor, and independant packages for each game.\r
  49 \r
  50 What kind of difference is there between project settings and prefs?\r
  51 Prefs would be user settings that survive throughout all games, \r
  52 whereas project settings are per-game / per-mod configuration. Turns\r
  53 out it's all a matter of loading the right configuration chunks at the\r
  54 right time.\r
  55 \r
  56 Proposed implementation:\r
  57 ------------------------\r
  58 \r
  59 Use key/values (== property bags) based on XML format for everything.\r
  60 Use them on project settings, and user prefs. The only difference\r
  61 between what would be project settings and what would be user pref\r
  62 is in which game configuration they are loaded, and how they are used.\r
  63 \r
  64 Project templates: We have a particular syntax to build settings from \r
  65 a 'template' version. Instead of loading a project template, we should\r
  66 be selecting a template from a list.\r
  67 \r
  68 Default startup: If we are configured to load last project on startup,\r
  69 load it .. otherwise display a list of games and templates?\r
  70 \r
  71 Module library:\r
  72 ---------------\r
  73 \r
  74 The dynamic loading / interfaces sharing / pure virtual classes needs\r
  75 to be implemented in a generic module. It should be the basis of the\r
  76 editor startup process.\r