mirror of
https://github.com/TTimo/GtkRadiant.git
synced 2024-11-10 07:11:54 +00:00
2b5ef55c7c
git-svn-id: svn://svn.icculus.org/gtkradiant/GtkRadiant/branches/ZeroRadiant.ab@187 8a3a26a2-13c4-0310-b231-cf6edde360e5
76 lines
2.7 KiB
Text
76 lines
2.7 KiB
Text
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.
|