slawekmikula wrote:
- tiles.xml -> location OK, Where to document format ? (I would like to make it nice and clean with all needed information placed somewhere - FGDATA/Docs (?) but what file or new one ?
- overlay layers - backend without any problem, I might have some help about nasal and dynamically create items in GUI (but i'll look at what already is done - maybe some hint where e.g. comboboxes or anything GUI related are populated dynamically in GUI from nasal ?)
- API keys - OK, sounds good. Same question about documentation placement (/sim/keys would be a place for other such kind of data)
FWIW, someone mentioned elsewhere that we cannot easily have application specific API keys that all end users could share ? If that's right, the property tree mains the right place for those keys, but the storage would belong into $FG_HOME
In other words, if it seems likely that each fgfs client will require its own set of API keys, those should not be part of defaults.xml or even $FG_ROOT, but they would have to be made persistent via the userarchive attribute, and then loaded automatically from $FG_HOME
Also note that the PUI/combo box thing is relatively awkward to implement, you can much more easily create a canvas combo box by using a scroll area with buttons, that become editable when clicked:
http://wiki.flightgear.org/Canvas_Snipp ... ScrollArea
http://wiki.flightgear.org/Canvas_Snipp ... Layouts.29
http://wiki.flightgear.org/Canvas_Snipp ... put_Dialog
This is also how the scroll-able airport-list widget was implemented:
http://wiki.flightgear.org/Howto:Proces ... ist_widget
In other words, you can simply create a function that traverses a well-defined location in the property tree to look for "api-keys" and then procedurally create the dialog, without having to hard-code any other assumptions (number/name of keys etc):
http://wiki.flightgear.org/Draw_masks
That way, you would end up with roughly ~50-100 lines of code to procedurally create a wizard to edit/manage API keys as needed, while storing them $FG_HOME
Such a dialog could then also load a README file from $FG_ROOT/Docs or show corresponding tool tips as needed, much easier and much less work than dealing with PUI/XML.