[Gtkradiant] some roadmap elements

[Timothee Besset]

I was talking with Spog about what's coming up on 1.2, and what stuff is 
there to do. I'll post some reflexions I had in the plane to Dallas, some 
kind of roadmap for the next major things coming:

* map module code

-> we need to have all the read/write operations to map files isolated 
behind an API, in an independent module. The squeleton already exists (see 
http://zerowing.idsoftware.com/viewcvs/viewcvs.cgi/GtkRadiant/plugins/map/ 
) and it needs to be finalized.
-> then we need to write a replacement module for this, which will only use 
the .xmap format, first version will work on .map or .xmap exclusively (no 
import/export between the two)
-> then we will work on making the two formats cohexist. I feel the default 
load/save should be .xmap, with functions to import/export .map. This 
sounds like it can be done with the current "minor version" scheme of the 
APIs, but probably not by using the filename extension (.map or .xmap) as 
the version (since .map would be valid for Q1 / Q2 / Q3). Other open issue 
is using a single module for Q1/Q2/Q3 .map since the formats differences 
are fairly small.

* abstraction of the component code into a standalone library

-> the objective being that Radiant AND q3map (and all other tools 
potentially) could use the same code for things like VFS, map parsing, file 
formats..
-> there is also potential use for the component library elsewhere (did I 
say DOOM?)
-> need to write down the exported functions etc.
   ideally the component stuff would work on a master/server approach like 
it does now. Master is an executable, client is a shared object with the 
required exports.
We want each component of the application to see a list of all APIs are 
available throughout the app. Components talk solely to the master, which 
will eventually forward the information to the related components. Some 
APIs are required for startup, being data driven this info is stored inside 
XML file and handed over to tje master so it can perform the job.
We have a string constraint though: the existing code must not change too 
much compared to the current scheme, because we have a LOT of components 
and plugins already.

Ok, that's about it. Then stuff I would be working on additionally to bug 
fixing on 1.1-TA and the next Q3 PR. When I get back from QCon things 
should start moving pretty fast again. I've posted the roadmap here for 
feedback and suggestions, so you guys are welcome to answer..

TTimo