Erik Hofman wrote:
Boris Koenig wrote:

I have now looked into dozens of source files, but I don't seem to be
able to find those files that are responsible for the XML handling,
respectively loading & parsing the PropertyList XML files, so I apologize in advance, but: what's the name of the classes that are used
or rather where do I have to look for this stuff ?

(I simply want to use FG's XML-handling capabilities for a specific function)

XML          : SimGear/simgear/xml/easyxml.?xx
Property Tree: SimGear/simgear/props/props_io.?xx

Thanks Erik !

> Do you want to parse XML yourself, or rather read an XML file into a
> property tree?

Actually, preferably only the second - this is something that we talked
about a couple of weeks ago: I asked you whether there would be any
way to deal with XML files in Nasal, (because I wanted to be able to
dynamically populate my Nasal-creted PUI controls using data taken
from XML -files) you said there wouldn't yet be any way to do this and
that this would require some thinking.

So I thought about ways to achieve this while keeping things simple- in
order to keep the overall overhead to a minimum level - after all I
don't need to use direct I/O in Nasal, so that's what I've come up with:

Two additional fgcommands to be called by Nasal

        fgWriteXML (SGPropertyNode * sourcepath, char *filename);
        fgLoadXML  (SGPropertyNode * targetpath, char *filename);

=> The first takes a path to a node within the property tree and
   iterates through it, in order to write all its elements to the
    file specified by  'filename'.

=> The second one loads the file specified by 'filename' and make all of its contents available within the property tree path specified by 'targetpath'.

Of course this is not yet particularly elegant and might cause
problems when it comes to XML files that exceed a certain size,
cause they would simply be dumped into the property tree ...

But for the near future it would probably be perfectly suitable
for my purposes.

Later on, one might still consider an approach such as the one that Jim
& Norman brought up yesterday in the "/sim/navdb" - thread, e.g. by only
exporting the *indexes* (i.e. toplevel nodes) of nested data to the
property tree and making data only available upon really ACCESSING a

That way the memory usage would be kept to a minimum and only those
nodes would really consume memory that are really accessed - the wrapper
that Jim mentioned is certainly not such bad idea, because something
like this could generally be used to minimize memory consumption by
nodes that are not accessed a certain amout of times within a
particular timespan - so a node would be classified depending on
the amount of times it is accessed ... but that's a different matter.

Regarding the specification of the filename for the XML loading mechanism, I've now also modified Andy's dialog.cxx to also support PUI's puFileSelector widget, so that you can easily create a corresponding PUI dialog with such a widget to ask a user to pick a certain file, the path/filename is then also stored within a temporary property tree node, like "/tmp/filename";

So, for now these are the types of modifications that I would
like to see added within the next time. I'm going to send
you the modifications as diff files by private eMail.

Most of this is not really a big change to FG itself - but
could still come in very handy - e.g. XML handling functionality
for Nasal would also mean that PUI dialogs could suddenly
offer users to PRESERVE settings/customizations - this is
something that's currently not yet possible.

Even though I have to admit that I am not yet fully sure about how
to implement the PropertyTree Node -> XML file mechanism (and vice versa).

It's not so much a logical problem, but rather I was hoping to get some insight about how FG handles these things from the code that's used to parse the PropertyList structures for all the other stuff - otherwise I would probably have to use some other XML-parser ...

So, I might very well have to ask about one thing or another ;-)

Cause, essentially I would prefer to use FG's inbuilt mechanisms - it
doesn't matter whether these items are then stored within a <PropertyList> tags or not, in the end it would probably not only save
some work and time, but also resemble reality - simply because what's
getting stored in these files IS indeed going to be a property list.

Sorry again, for the long posting, Erik ;-)

--------- Boris

Flightgear-devel mailing list

Reply via email to