docs/developer/data-driven-design.txt

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