1c68299599573dcb6e20db93f98cbf8d0ec522cd
[xonotic/netradiant.git] / 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.