Re: [Flightgear-devel] Help with XML and preferences.xml
Jonathan Polley writes: I have made an attempt to describe the contents of 'preferences.xml.' Could someone knowledgeable in the properties list and preferences.xml file let me know if I am understanding things correctly? Also, is there any information about what each component of FlightGear needs from the property list (i.e., the various FDMs, etc.)? http://homepage.mac.com/eq_fidget/FG_Dox/preferences_xml.html Just to start, the property tree has nothing to do with Metakit -- we use Metakit only to hold airport and navaid data. path Aircraft/c172/Panels/c172-vfr-panel.xml/ path This tells FlightGear where it can find the configuration information for the aircraft. It is the same as using the '--aircraft-dir=' option. Actually, this is the path to the default instrument panel. --aircraft-dir is a special option used only by UIUC. Thanks for starting on this -- it's much needed. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
Just to start, the property tree has nothing to do with Metakit -- we use Metakit only to hold airport and navaid data. I will make that change. path Aircraft/c172/Panels/c172-vfr-panel.xml/ path This tells FlightGear where it can find the configuration information for the aircraft. It is the same as using the '--aircraft-dir=' option. Actually, this is the path to the default instrument panel. --aircraft-dir is a special option used only by UIUC. Thanks for starting on this -- it's much needed. Some of the other XML files are rather easy to figure out (i.e,. keyboard. xml), but others are not (i.e., the FDM specific files). Does anyone have anything written that describes these? The materials.xml file has quite a nice description at the top. Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Help with XML and preferences.xml
Some of the other XML files are rather easy to figure out (i.e,. keyboard. xml), but others are not (i.e., the FDM specific files). Does anyone have anything written that describes these? The materials.xml file has quite a nice description at the top. Can you let us know what is unclear in the FDM files so we can write up a better explanation? Thanks, Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
Jonathan Polley writes: Some of the other XML files are rather easy to figure out (i.e,. keyboard. xml), but others are not (i.e., the FDM specific files). YASim and JSBSim each uses its own XML format, which is different from the XML format used by the rest of FlightGear. For YASim, see $FG_ROOT/Aircraft-yasim/README.yasim in the base package; for JSBSim, see the documentation at http://jsbsim.sourceforge.net/. UIUC uses a non-XML config-file format. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
On Sunday, March 17, 2002, at 09:53 AM, Jon Berndt wrote: Some of the other XML files are rather easy to figure out (i.e,. keyboard. xml), but others are not (i.e., the FDM specific files). Does anyone have anything written that describes these? The materials.xml file has quite a nice description at the top. Can you let us know what is unclear in the FDM files so we can write up a better explanation? I think this is more along the lines of my not what is important to each FDM when it comes to configuration. If I wanted to configure a Boeing 707 model by modifying a 747 model, what is needed for each FDM type? When I look in YASim, I see quite a bit of information, but I don't know what it pertinent. What does it mean to add or remove an engine to the various FDMs? How do I define the characteristics of an engine? All of these questions come about because I am unfamiliar with how the FDMs are put together and how they work. My documentation effort is driven by my lack of understanding on how things work, and my assumption that I am not the only one ;) On that topic, I have some updates to the preferences.xml documentation http://homepage.mac.com/eq_fidget/FG_Dox/preferences_xml.html Thanks for the info, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
I have made an attempt to describe the contents of 'preferences.xml.' Could someone knowledgeable in the properties list and preferences.xml file let me know if I am understanding things correctly? Also, is there any information about what each component of FlightGear needs from the property list (i.e., the various FDMs, etc.)? http://homepage.mac.com/eq_fidget/FG_Dox/preferences_xml.html Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
Wolfram Kuss writes: The XML files get IMVHO more and more confusing. I think that it would be more accurate to say that FlightGear is getting more sophisticated -- there's more to learn if you want to customize things, but that's only because there's so much more that you can customize. The config files serve many different purposes; using the XML-based property-list format for all of them helps a lot, since it allows some common structure and reusable code among all the formats. Imagine if we had one file format for preferences, a different one for panels (say, with fixed-length fields), a different one for saving a flight (perhaps a binary format), another one for sound configuration (perhaps an INI file), a different one for top-level aircraft configuration (perhaps CSV), yet another one for configuring 3D models (perhaps embedded data strings in the 3D files themselves), etc. etc. I saw that for example the spelling of z-offset changed twice and I was told to use a third spelling. Also, it is not clear to me, what the different xmls are for (what does -dpm, -set etc mean? set as in set options? Don't all xmls set options?) and whether you can use all properties in all XMLs and whether you can use all on the command line. Yes, we're still in early days with some of this. Again, these are config files for totally different purposes, and the fact that they all use XML is simply a convenience for programmers and customizers. Here are some of the conventions that we've come up with so far, partly ad-hoc (all paths relative to $FG_ROOT): preferences.xml- the top-level default preferences joysticks.xml - default joystick bindings, included by preferences.xml keyboard.xml - default keyboard bindings, included by preferences.xml Aircraft/*-set.xml - aircraft-specific settings, overriding the defaults in preferences.xml (and joystick/keyboard.xml) As far as I can recall, these are the *only* files in the base package that affect FlightGear's main property tree. Other files use the property-file format for convenience to populate various data structures, but they do not touch the main tree and are not accessible through the property browser or through the command-line --prop: option; it's just a coincidence that they also use the property-list format: materials.xml - define the materials (textures, colour, lighting) for use in the scenery HUDS/**/*.xml - configuration files to define the various heads-up displays Aircraft/*/*-sound.xml - configuration files to define sounds played for various aircraft Aircraft/*/Panels/*-panel.xml - configuration files to define 2D panels for various aircraft. Aircraft/*/Instruments/*.xml - configuration files for individual instruments included by the 2D panels. Aircraft/Instruments/*.xml - ditto We also use some XML-based formats that do not (yet?) follow the property-list conventions, including the following: Aircraft/*/*.xml- JSBSim aero model config files Aircraft/Aircraft-yasim/*.xml - YASim aero model config files Engine/*.xml- JSBSim engine and thruster config files So, a UI that showed you what you can do would be very nice. Agreed. Since the property-list format is used by most of the config files, it will be a relatively easy job to write a generic browser for all of those formats (like the property browser inside FlightGear). Then all you need is a simple schema format (which can also be property-list-based) to say what is and isn't allowed in each format, and the UI will be dynamically reconfigurable. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
* [EMAIL PROTECTED] (David Megginson) [2002.03.10 10:47]: Jim Wilson writes: Hehe. Yep. Didn't notice that one. Actually I don't know why that would be in the preferences.xml. Anyone know why that isn't in the panel or at least aircraft-set xmls? A cleanup and reorg is long overdue; same for keyboard mappings. David and I briefly discussed changing the keyboard XML schema back in November. If anyone is considering reorganizing the keyboard XML, please consider what we came up with: http://mail.flightgear.org/pipermail/flightgear-devel/2001-November/001134.html http://mail.flightgear.org/pipermail/flightgear-devel/2001-November/001136.html Well, back to RL... Thanks -- Cameron Moore [ Why doesn't Tarzan have a beard? ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
Cameron Moore writes: [ Why doesn't Tarzan have a beard? ] Jane, n'est-ce pas? All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
David wrote: Wolfram Kuss writes: The XML files get IMVHO more and more confusing. I think that it would be more accurate to say that FlightGear is getting more sophisticated -- there's more to learn if you want to customize things, but that's only because there's so much more that you can customize. I wrote my critizism so that things will be improved, not to critize someone and certainly not one of the most active devlopers. I do admit I was a bit frustrated, since I have slept little for at least a month now and my current non coding free time is listening to tapes on the work to and from work. So, I got frustrated when I needed an hour or two just to find out the name of a parameter. So, IMHO, we should try to not change *after* 0.8.0 (or 0.7.10) again. Also, it was meant as encouragment to write a UI; If you can simply choose from possible parameters, you don't need to hunt for its name. If noone does a UI then one thing one can do is have a commmand line parameter to fgfs that forces it to write out all possible properties etc. I would guess fgfs has a complete list of these somewhere? The config files serve many different purposes; using the XML-based property-list format for all of them helps a lot, I am not arguing against XML. There are several things unclear to me that IMVHO should be (better) documented. preferences.xml- the top-level default preferences joysticks.xml - default joystick bindings, included by preferences.xml keyboard.xml - default keyboard bindings, included by preferences.xml Aircraft/*-set.xml - aircraft-specific settings, overriding the defaults in preferences.xml (and joystick/keyboard.xml) This should be in the Docs (or did I miss a major XML doc? I only read the http://www.megginson.com/flightsim/fgfs-model-howto.html ). As far as I can recall, these are the *only* files in the base package that affect FlightGear's main property tree. Other files use the property-file format for convenience to populate various data structures, but they do not touch the main tree and are not accessible through the property browser or through the command-line --prop: option; it's just a coincidence that they also use the property-list format: I see. At the beginning, this was unclear to me although I more or less realized this after a bit. Calling things properties that are not --prop: things is IMHO not a good idea. BTW, in your list you forgot the *-dpm.xml files, which are of most interest to me and which are currently the only ones that I really use :-). With the little time I currently have, I am glad if I manage to have a nice 3D model at the correct place in fgfs. All the best, David Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
Wolfram Kuss writes: BTW, in your list you forgot the *-dpm.xml files, which are of most interest to me and which are currently the only ones that I really use :-). With the little time I currently have, I am glad if I manage to have a nice 3D model at the correct place in fgfs. Ah, yes -- a file with the same name as a 3D model and the XML extension is a wrapper file for the 3D model containing animation and placement information. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Help with XML and preferences.xml
Does anyone have some documentation on how to build the preferences.xml file? I would like to write a preferences manager, if such a tool does no already exist, to make it easier to manage multiple aircraft configurations and settings. The goal for tool is as follows: Language: python 2.x (I know the language and it has good XML tools) GUI: Tk (Tkinter is the standard GUI interface for python) Features: Load XML file, edit it, provide save/save as. I also need to know how FDM specific the preferences file is. I have some experience with Tkinter. but my GUIs tend to be a bit functional (OK, ugly), and I will be learning XML at the same time. Any, and all, help will be greatly appreciated. Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Help with XML and preferences.xml
Jonathan Polley writes:
I have some experience with Tkinter. but my GUIs tend to be a bit
functional (OK, ugly), and I will be learning XML at the same
time. Any, and all, help will be greatly appreciated.
If you know LISP (CommonLISP, InterLISP, Scheme, E-LISP, or what-have
you), you're most of the way there.
Think of an XML document as a single toplevel LISP list containing any
number of nested sublists. The top-level list and every sublist are
called 'elements' in XML, and each starts with NAME and ends with
/NAME, where NAME represents the name of the element. So, what you
might represent in LISP as
('person ('name David Megginson) ('citizenship Canadian))
you can represent in XML as
person
nameDavid Megginson/name
citizenshipCanadian/citizenship
/person
An element name must begin with an alpha or '_', and may contain only
alphabetic characters (actually, most Unicode ones, including Chinese,
Arabic, etc.), numerals, '_', '-', or '.'. Technically, they can also
include ':', but that can cause conflicts and should be avoided.
The text inside an element can contain pretty-much all printing
characters, but '' and '' (and sometimes '') must be escaped, like
this:
amp; =
lt; =
gt; =
So in XML text, for a b c d, you'd have
a lt; b amp;amp; c gt; d
It's a bit ugly, but it works.
Comments in XML start with !-- and end with --; they may not contain
the string -- in-between.
You can attach variables, called 'attributes', to each element by
putting a name=value pair in the start tag, like this:
a href=http://www.flightgear.org/;FlightGear/a
The attribute name is href (follows the same rules as element
names), and the value is http://www.flightgear.org/;. The value must
always be quoted with ... or '..', and in addition to the special
character escapes I mentioned above, you can also use the following:
apos; '
quot;
To encode
He said it's best to buy ATT
in an attribute value, you'd do something like
quotation text=He said quot;it's best to buy ATamp;Tquot;/
or
quotation text='He said itapos;s best to buy ATamp;T'/
How elements and attributes are interpreted is almost entirely up to
the application -- XML says how to encode data, but not what the data
means or how it should be processed. In the property manager, we've
decided to treat the XML document like a file system: the root element
(PropertyList) is the filesystem root, and everything else is a
subdirectory or a file (leaf data).
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
On Sunday, March 10, 2002, at 07:02 PM, David Megginson wrote:
Jonathan Polley writes:
I have some experience with Tkinter. but my GUIs tend to be a bit
"functional" (OK, ugly), and I will be learning XML at the same
time. Any, and all, help will be greatly appreciated.
If you know LISP (CommonLISP, InterLISP, Scheme, E-LISP, or what-have
you), you're most of the way there.
Now I am going to have nightmares ). LISP and I were not the best of friends in college (things like caadaddaddr gives me chills).
Think of an XML document as a single toplevel LISP list containing any
number of nested sublists. The top-level list and every sublist are
called 'elements' in XML, and each starts with NAME> and ends with
/NAME>, where NAME represents the name of the element. So, what you
might represent in LISP as
('person ('name "David Megginson") ('citizenship "Canadian"))
you can represent in XML as
person>
name>David Megginson/name>
citizenship>Canadian/citizenship>
/person>
I believe that python maps dictionaries to XML. The above would be something like:
Someone = {'person': {'name': 'David Megginson',
'citizenship': 'Canadian'}
}
print Someone['person']['name']would yield
'David Megginson'
Since python has a nice mapping between class membership and dictionaries, it may be cleaner than that.
Jonathan Polley
Re: [Flightgear-devel] Help with XML and preferences.xml
Jonathan Polley [EMAIL PROTECTED] said: The preferences file is not FDM specific at all. The contents of preferences.xml in the base package are for the most part self explanatory, I have to beg to differ on this one. For those few command line arguments that I have used, I can find mappings in the preferences files. Where I do not kow the command line arguments, the preferences file is not very clear. For example: instrument-options nav n=0 has-gs-needle1/has-gs-needle needles-pivot1/needles-pivot /nav nav n=1 has-gs-needle0/has-gs-needle needles-pivot1/needles-pivot /nav hsi n=0 has-gs-needle1/has-gs-needle /hsi dg style0/style /dg /instrument-options Hehe. Yep. Didn't notice that one. Actually I don't know why that would be in the preferences.xml. Anyone know why that isn't in the panel or at least aircraft-set xmls? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
Jim Wilson writes: Hehe. Yep. Didn't notice that one. Actually I don't know why that would be in the preferences.xml. Anyone know why that isn't in the panel or at least aircraft-set xmls? A cleanup and reorg is long overdue; same for keyboard mappings. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
If you know LISP (CommonLISP, InterLISP, Scheme, E-LISP, or what-have you), you're most of the way there. Now I am going to have nightmares ). LISP and I were not the best of friends in college (things like caadaddaddr gives me chills). Actually, I think they're referring to nested property lists and not to the exciting tricks that can be played with the CONS operator. Another sneaky bonus of XML over LISP is in the bracketing. Instead of having fifteen close parentheses stacked up at the end of the function, you get to say /a/b/c/d/e/f etc. While this is a pain in the butt to type, at least the compiler has a chance of noticing any mistakes. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
On Sunday, March 10, 2002, at 08:04 PM, Alex Perry wrote: Another sneaky bonus of XML over LISP is in the bracketing. Instead of having fifteen close parentheses stacked up at the end of the function, you get to say /a/b/c/d/e/f etc. While this is a pain in the butt to type, at least the compiler has a chance of noticing any mistakes. Which brings to light the old joke about what LISP stand for: Lots of Idiotic Stupid Parenthesis I also never got far enough to find out how to comment a LISP program. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
Sounds like a worth while (sp?) project! The XML files get IMVHO more and more confusing. Maybe lets do the big reorg that Dave speaks about first, with the hope that things won't change often afterwards. When doing the python scripts to generate the very very rudimentary plane xmls on my website http://wolfram.kuss.bei.t-online.de, I saw that for example the spelling of z-offset changed twice and I was told to use a third spelling. Also, it is not clear to me, what the different xmls are for (what does -dpm, -set etc mean? set as in set options? Don't all xmls set options?) and whether you can use all properties in all XMLs and whether you can use all on the command line. So, a UI that showed you what you can do would be very nice. If you use python, you can include my stuff. I would love someone expand on it and say I download a MSFS 3D model, Python unpacks it, moves all files, generates warnings if applicable telling me what to do (for ex.: !This is an old MSFS 95 model, you need to convert it with the MS converter first, sorry!), lets me create a *.ppeloc file, generates the XML file with the z-offset and the pitch-deg for me, lets me choose a FDM, panel etc, inputs it into the XMLs, generates a small batch file to call everything, etc. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
On Monday 11 March 2002 02:32 am, you wrote: Sounds like a worth while (sp?) project! The XML files get IMVHO more and more confusing. Maybe lets do the big reorg that Dave speaks about first, with the hope that things won't change often afterwards. When doing the python scripts to generate the very very rudimentary plane xmls on my website http://wolfram.kuss.bei.t-online.de, I saw that for example the spelling of z-offset changed twice and I was told to use a third spelling. Also, it is not clear to me, what the different xmls are for (what does -dpm, -set etc mean? set as in set options? Don't all xmls set options?) and whether you can use all properties in all XMLs and whether you can use all on the command line. dpm == Davids initials set == set of components, as in the set comprised of panel A, model B and FDM C. I wasn't thrilled with it when I thought of it, but I had to do something to avoid confusion because the FDM config files have nothing to identify that they are for the FDM in the filename. So, a UI that showed you what you can do would be very nice. If you use python, you can include my stuff. I would love someone expand on it and say I download a MSFS 3D model, Python unpacks it, moves all files, generates warnings if applicable telling me what to do (for ex.: !This is an old MSFS 95 model, you need to convert it with the MS converter first, sorry!), lets me create a *.ppeloc file, generates the XML file with the z-offset and the pitch-deg for me, lets me choose a FDM, panel etc, inputs it into the XMLs, generates a small batch file to call everything, etc. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
On Monday 11 March 2002 02:32 am, you wrote: snip choose a FDM, panel etc, inputs it into the XMLs, generates a small batch file to call everything, etc. The set files do what said batch file would do. They are the top level aircraft config. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
