Erik Hofman wrote:
Boris Koenig wrote:
woohoo - don't say that: I was just about to make a terrible mess of
the code ;-)
No need, that has already been done.
what...the feature or the 'mess' ? :-)
Alternatively, I was thinking of either using a separate fgcommand that
pushes the data in the property tree when requested - so one would
basically still have something like:
/sim/navdb/vor
/sim/navdb/ndb
/sim/airports/
What would be an idea is to use an fgcommand that looks at (for example)
/sim/navdb/id and returns the data of that particular id in
/sim/navdb/vor et all.
right, that's exactly what I was talking about - one would only need
to use an accessor string within the property tree.
The problem is then though, that the navaids db certainly contains
various navaids using the same ID - so the fgcommand would need
to return an _array of replies_, which will then be checked for their
positional data, in order to make sure that you retrieved the correct
navaid.
I would also like to add support for puPopup's as well
as exporting the menubar to the property tree - so that
it can be populated/changed dynamically - any objections ?
Popup dialogs should already be supported.
I wasn't talking of 'dialogs' but rather menus:
context menus - I don't think anybody else would
really require it, but I pretend to need it ;-)
Also, it's not that much of a change, either.
Generating a dynamic menu structure might be harder than you think,
Hmm, you may be right - I haven't yet really looked into the source
code.
Anyway, so let's share what I "think":
=> export the entire menubar.xml file with its items
into something like
/gui/menubar/structure
Now all menus and menu items would be stored in that path within
the property tree.
So the property tree holds then something like this:
/gui/menubar/structure/menu[0]/label
=> "File"
/gui/menubar/structure/menu[0]/item[0]/label"
=> "Load"
/gui/menubar/structure/menu[0]/item[0]/binding[0]/command[0]"
=> "nasal"
/gui/menubar/structure/menu[0]/item[0]/binding[0]/command[0]/script"
=> print("......");
which would be the equivalent of:
<menu>
<label>File</label>
<item>
<label>Load</label>
<binding>
<command>nasal</command>
<script>print("......");</script>
</binding>
</item>
</menu>
That way, the whole menubar.xml could be put into the property tree,
and could easily be modified using a nasal script, that can either
change an existing menu/-item or simply add new ones by using the
absolute paths like shown above.
So, one would ultitmately have "self-registering" nasal scripts.
Regarding the updating of the menubar itself one would either need to
fire an event if any node changes and do the updating automatically
OR use a separate fgcommand that re-creates the menubar based on
what it finds in the corresponding sub-path of the property tree.
the best option is a triggered
reload I guess (which is already supported, see Debug->Reload GUI).
yes, right - I know, but that would require a (manually) modified
menubar.xml, but I don't want to modify it statically, rather I
envision something like the following:
drop a nasal file into $FG_ROOT/Nasal, which then
get's loaded as module.
now this module needs to customize the menubar,
because it has some nifty new dialog or other
functionality, USUALLY this would require to
MANUALLY edit menubar.xml and add a the stuff.
WITH such an exported property tree, a Nasal script
could make its own commands available to the user,
without the need to modify the menubar.xml.
The motivation behind all this is, that I have a couple of smaller
nasal scripts that I would like to "auto-add" themselves on demand.
PLIB/PUI does currently not support submenus, so one would ultimately
end up having pretty unsorted menus, the more stuff gets added, the
less items can you place there - but having the possibility to
dynamically populate the menubar would mean that scripts can
compensate for the lack of submenus.
But you are of course right: I haven't yet really looked into it,
and might think that it is easier than it really is ...
--------
Boris
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
