Sorry folks, this going to be a longer one ...
Andy Ross wrote:
Boris Koenig wrote:
Thanks for the answers so far, I was already playing around with the gui.nas file, will have to look into it in more detail in order to see how to get the positioning part done, though.
Essentially, you can just set x and y properties on the top level gui object.
Yes, thanks for that - actually I meant _positioning_ part - I have now decided to simply use "\n"s for that purpose :-)
Regarding the positioning, I did only have to additionally provide my own x/y values to a copy of the popupTip function - without really looking much into the widget object itself.
There is a "Widget" helper class in there that can take some
of the tedium out of handling the raw property interface. See the code for the fuel/weight dialog (gui.showWeightDialog()), which uses
this API.
yes, thanks - I was going to ask you about that weight dialog anyway:
isn't that what you are doing there exactly what I wanted to do when I asked about "dynamically creating dialogs/dialog-elements using Nasal" - instead of using the hard-coded XML-files ?
I'm not sure if you remember, but some time ago I posted a screenshot of FG showing a XML gui file with various dialogs and controls that I created manually, here:
http://flitetutor.sourceforge.net/include.php?path=content/content.php&contentid=23
So, it seems like I can already create the dialogs itself - not sure
about how well all of the controls are supported, though - (like, edit box, combo, buttons).
But I did meanwhile play around with the mechanism that you used in that example, and I'm surprised to see that it _seems_ already quite possible to dynamically create a gui ... I haven't yet tried to create every PUI - control, but so far it's already extremely usable.
Besides the fact, that combo boxes seem to be opened upwards by default - which is not feasible in some situations (e.g. look at the upper dialog on the screenshot) - so, an additional property like "upwards/downwards" might be useful - cause PUI itself allows such a specification already.
Also, it seems to me that that the width property for combo boxes isn't being properly dealt with - even though I can (dynamically) create a PUI combo box control, the width value for that particular control does seem to be ignored - it's always displayed using a fixed width (no layouting applied !) - if you want me to send the corresponding code, just tell me.
I will get back to the original replies within the next days, but a quick question: is there any way to make FlightGear re-initialize the Nasal loading routines ?
Not currently. Adding it wouldn't be difficult, but the interaction issues can be very complicated. Existing Nasal code (loaded via the aircraft XML or other configuration) might be holding references to values in the the pre-existing modules.
Okay, so then it would make more sense, to not only re-load the modules in /Nasal/ itself but rather also all the other stuff in order to circumvent potential problems ?
So, basically I would also need to use
void FGNasalSys::loadPropertyScripts()
again, in order to load the Nasal scripts from the property files ?If those get used, you can end up in a situation where the "old" and "new" versions of the file are in use simultaneously.
Likewise, think of timers registered by
the "old" version that get run after the new one is loaded.
but, this shouldn't happen if the other Nasal code gets reloaded, too - right ?
But if you are careful about things and/or willing to troubleshoot
this kind of issue, there's no reason it couldn't be done.
I was actually not even looking for a really fool-proof way, rather it would already be perfectly sufficient not to have to re-start FG each time for every single modificiation to one of the Nasal-modules.
So, I would not mind doing all the reloading again.
Take a look at NasalSys::init() in src/Scripting/NasalSys.cxx. You'll want to extract the loop at the end (where it loads the files) and make it available as a fgCommand binding like "nasal-reload" or somesuch.
Thank you ! That was as helpful as the source code itself :-)
You'll want to delete the pre-existing modules first, of course (by doing something like "globals.gui = nil;", either in Nasal or using the extension API).
As I'm not really familiar with all the internals, the safest way would probably be, to simply 'nil-ing' all the modules manually using Nasal, instead of actually deleting the hashes within FG, I think.
Also, what's the preferred way of implementing a basic "event loop" using Nasal, I've played around with this by using either a normal loop, or a timer - what's the best choice to poll a certain node from the property tree and act upon it assuming a certain value ?
Basically, I want to monitor several nodes at once and call a function (that then changes other properties) as soon as a certain condition is met.
--------- Boris
P.S.: To the doc-maintainer(s): How about adding all the Nasal documentation at plausible.org directly into the base-package's /Docs/ folder ? I think it would be quite useful, possibly enhanced with some more real-life Nasal examples taken from those .nas files or property lists. I am already assembling a Nasal FAQ file, that can later be added to the Docs folder.
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
