Erik Hofman wrote:
Boris Koenig wrote:

Maybe it is now easier for you to tell me, IF the desired functionality
could be (easily) achieved using primarily nasal scripting and some
smaller FlightGear source code modifications or whether it would
be more feasible for me to really start writing directly into the
FlightGear source. Even though I am more and more about to like
the Nasal way, which seems to be pretty elegant by the way.


I think (after reading the whole message) that FlightGear just needs a few modifications. Two come to mind:

1. load a new panel at runtime (refreshing the panel is already possible)
2. add XML I/O support to Nasal.

okay, meanwhile I had some time to look into the gui/panel-files that you mentioned. And I do think the existing way to "describe" the panels could indeed be used for my purposes-even though I would actually prefer a somewhat less static and more dynamic solution-if you know what I mean:

I  wonder now is if it's really *necessary* to provide such external
descriptor files or if Nasal itself could be used/modified to do exacty
that job WITHOUT having to rely on external files.

I'am asking that because I think that would allow some more flexibility
to be used- e.g. what I've thought about as a workaround would for
example be passing a pointer to a dynamically-built array with some XML
data directly to FlightGear, but BY USING Nasal-so there would not be
any need for external files.

So, if possible I would like to be able to use a Nasal script itself for
these purposes and not have to rely on external files. This particularly
because I would like to be able to dynamically create files that contain
all necessary information and don't need to be distributed within the
whole FlightGear install tree.

That way Nasal itself would create a variable containing the necessary
XML-statements and pass a pointer of that variable to FlightGear in
order to make it process it.

I currently don't imagine something like that pretty complicated
to be implemented for Nasal.

What do you think, would something like that be EASILY possible ?

Of course, what I would consider even more elegant would be a specific
Nasal Hook to dynamically make the underlying subsystem create a
dialog/panel on the fly.



Here's a short example - I fill in some parameters like:

//Create a new dialog
newDlg=setprop("/subsystem/../createDlg[0]",1);

//Set Dimensions for that Dialog
setprop(newDlg,"dimensionsX[0]",200);
setprop(newDlg,"dimensionsY[0]",100);

//Set Position on screen:
setprop(newDlg,"positionX[0]",100);
setprop(newDlg,"positionY[0]",200);

//Create a new Button
newButton=setprop("/subsystem/../createBtn[0]",1);

//Set some text to be displayed on the button
setprop(newButton,"legend[0]","Test Button");


I think -so far- this shouldn't really be too complicated and using such a method you could Nasal use for many purposes which otherwise seem only possible by using XML-Files directly.

The same method could be applied to allow dynamic (Nasal based)
creation/modification of panels.

I have already looked into  the code and think such modifications
should be possible.


The way I see it, a panel object could be used as a "sheet" containing the necessary information (animated instruments, text and static graphics).

okay, this sounds okay - I've already checked out some panels and it seems it is possible to create pretty customized panels- that for example do not need to use the screen's whole width (please tell me if I am wrong).

The next problem that I am seeing though, is that these panels might be
hard to dynamically get populated. That's why I suggested a method like
the one above to be used.

Because, while it is currently possible to place a label at a certain position, showing a certain text, I have not found a way to access such
a property using Nasal in order to - for example - change either the position of a label "on the fly" or the text that's getting displayed.



This would require FlightGear to load another "sheet" (panel) when requested to continue. I don't think that's too tough of a problem.

As I mentioned, such actions should be possible to be implemented using dynamic registration of events & actions - that way it should be possible to "bind" actions to certain controls - pretty much the same way that it is now already done in the config files. Though, a bit more advanced, cause I would also like to be able to react to mouse events in certain regions. I do remember that you told me something like that could be achieved by using instrument definition files, but I wouldn't want to use such a functionality merely for instruments, but pretty much to most controls.

For example I would like to be able to notice a
"click and hold mousebutton" event and allow then some simple
drag & drop.
(This would be necessary in the authoring part of the application)



The way you are suggesting it, seems to require a particular
sheet/panel definition file for EACH page(=panel) - right ?


(I have already created a basic framework using Nasal by doing exactly that, but there are still some shortcomings that might be easily overcome if Nasal is approriately enhanced or at least some more binding are made available)

Contrary to the "each page needs to be an indidvidual panel" method,
I would like to be able to do something like the following:


<learning_unit title="test unit" description="This is just a test"> <page no="1"> <layer id=0> <!--In order to display a text label --> <text> <x>50</x> <y>400</y> <label>Introduction</label> </text>

                        <button>
                          <x>5010</x>
                          <y>350</y>
                          <legend>Go</legend>
                        </button>
                </layer>
        </page>

        <page id="2">
                <!--- other stuff --->
        </page>

        <page id="3">
                <!--- even more other stuff --->
        </page>

        <!--
        ....
        --->

</learning_unit>

So, I would like to be able to describe the whole set of pages within
ONE external script file, that THEN gets processed by Nasal's (yet to
come) XML-bindings.


IF there is already a way to dynamically address elements that that are
created using a static XML file, I'd appreciate it if you could tell me about it-or maybe you have some other usable workaround ready ? :-)


On the Nasal page I've read it would be possible to make such
things available using a specific namespace where stuff then gets loaded
into ?


Adding XML I/O to Nasal might be a bit harder to do.

I didn't mean to require a fully featured parser - rather some simple way to retrieve the contents of a XML file in order to dynamically deal with it - but of course also to allow authoring AND storing of each lesson unit.

As you certainly have read, I would not only like to be able to
"play" such units within FlightGear, but also -using a 2nd module-
to allow simple authoring means to create these within FlightGear.

In that regard, the authoring module is even more likely to become
"complex" than the actual "player"  as it would require things such as:

        -       dynamic positioning of elements by using the mouse
        -       storing these positions in a XML file
        -       using variables for properties

etc.


I guess the only thing that actually could be done by loading an XML
document in Nasal
would be to load a new set of pre-defined properties. While this is useful, it might be easier done using C++ instead.

I've checked out the Nasal<->FlightGear "docs" and there's one way mentioned to call not only FlightGear commands directly using FGcommand, but also to make general use of externally (c++ implemented) functions.

What I could therefore imagine to be feasible is either another
FGCommand that binds some high-level XML functionality to Nasal.

OR really use the corresponding C++ Classes themselves, though I
am not sure how easy it is to add a simple abstraction layer to that
using Nasal - as I certainly would only need a pretty abstract
functionality - the way you just described it, to load pre-
defined properties might indeed be one option, I will have to
check this out in detail - also in order to see if I can create
some general header that describes the XML file closely enough
to be dynamically used by Nasal to process its contents.

But I think I could cope with XML-Files (respectively their contents)
being made available within Nasal as a specific property sub-tree.

I currently imagine something like that:

//Pass XML-File to be loaded
newhandler=setprop(/subsystem/../loadXMLFile[0]",1);

//Specify the filename to be used
setprop(newhandler,"filename[0]","filename.xml");

//then provide the toplevel tree-node that shall be used
//to store the properties of that XML file:
setprop(newhandler,"useNode[0]","/FliteTutor/Lessons/current[0]");

I hope, that's somehow understandable :-)


What could not be done using Nasal (and probably never will, although I really would like to see this added for the Radar object) is to load and manipulate 3d objects using Nasal *directly*. Andy (the author of Nasal) has clearly stated that this is probably really hard to do.

Well, something like that might really be pretty useful - as I understand it so far, all this stuff is currently done using a XML config file, then how about thinking of a way to put each XML config file into a certain Nasal-namespace, whose elements would then also be available to Nasal ?

Like a way to access properties OF AN XML-(ANIMATION)-File ?
But this would really be another topic...

This might be a usable workaround, if I understand things correctly of course.
Otherwise, there might be also the option that I mentioned a couple
of paragraphs above, to use "on the fly" created animation files in
XML format but don't actually store them on the disk, rather pass
their contents as a pointer to the relevant FlightGear function.


Further more, I really think you shouldn't consider "not loading subsystems" because that's impossible right now.

I was just thinking of a way to speedup the FlightGear boot process on the one hand, but then also to make only use of the stuff that need's to be running.

Simply, also because it would help me not to have to wait for each
subsystem to start, that I am going to disable anyway.

Maybe I can find some command-line parameters that serve the
same purpose in the meantime, for debugging purposes I really will
only need FlightGear's GUI - all the other stuff should really be
only available on demand und shouldn't consume CPU/GPU time

Instead it would be easier to disable subsystems after they have been loaded.

Okay, I see - for now that shouldn't really be much of a difference, except maybe for the amount of time it takes for FlightGear to be fired up.

On the other hand, what I just thought about - it might be possible to
specify a certain element in .nas-files that describes what needs to be
running - and these parts could be parsed and evaluated by the
initialization routines.

So, provided I've passed a specific nasal file as parameter, FlightGear
might first check IF that file needs only certain subsystems, and which
of them.

OR there might be a standard-property which specifies exactly WHICH
systems need to be running.

Well, but that's currently certainly not essential.


As far as I can tell, all subsystems that allow disabled don't consume any CPU/GPU time.

Well, I have some doubts regarding that - as I mentioned above, I've already tried some things out using Nasal and all my scripts use

/sim/rendering/draw-otw[0]=0
/sim/panel/visibilty[0]=0

And while the stuff DOES get HIDDEN - and the framerate increases,
I still see some background stuff  every couple of seconds.

It's kind of "flickering" every 5-10 seconds - and seemingly that stuff
IS updated ! - So I GUESS the view is merely disabled, while the
background processing (calcuations) is still being made.

Hence, it might be useful if I could REALLY disable certain subsystems
or at least make them go into "idle" state as long as I need it.


But as I mentioned previously: if I am shown HOW TO add Nasal
bindings to FlightGear I wouldn't mind firing up my IDE and
do some C++ stuff myself.


There are some hints at the bottom of the document I mentioned earlier, but it's not very comprehensive.

Yes, thanks I've printed out that stuff already - and I agree: it's really not that comprehensive.


[GENERAL]
    -    position and alignment of GUI elements for
         navigational purposes
    -    title of unit
    -    introductory description (outline)
    -    pages that exist for that unit


This can all be done in the panel configuration file.

yes, sure - Meanwhile, I have already done some of these things using static XML-files at solutions - but I'd rather really want to do these things dynamically - hence my suggestions.


So, each unit/lesson would then consist of different "pages" -

(read panels here)

okay, btw: I noticed that "dialogs" all seem to rely on a hardcoded position under /gui/dialogs - is there another way to specify a custom location, cause I simply wouldn't want my stuff to mess up the standard installation.

I would rather want to to use a subfolder of $FGROOT -
what I tried so far didn't work, though :-/


Hence, I would nasal need to be able to do mainly the following stuff:

    -    draw abitrary (plib based) GUI elements within
        FlightGear's client area

That can be done now.

YES BUT ONLY USING EXTERNAML PANEL CONFIG FILES - obviously not using Nasal from within a .nas-script ?

Tell me, if I am wrong !

    -    register (nasal based) callbacks/handlers for controls
        such as buttons,textboxes etc.


That is already present, but it might work a bit different than what you are hoping for.

I've looked into what's been written in the Nasal<-> FlightGear doc and I think it *might* be usable, with some smaller extensions - for example, in order to also support enhanced hooks for mouse-actions etc.


    -    register callbacks to act on certain mouse events
        within FlightGear


This is done using the instrument configuration file.

Yes, I know - but this wouldn't be sufficient, as I would also want to react on specific GUI-events - WITHOUT any instruments being present at all.

So, the purpose of the authoring component would also be to allow
dynamic repositioning of elements such as graphics, buttons or
whatever - for that very purpose I would need to be able to
do things such as setting Mouse-Hooks.

Example given:
        -       If  Button X has been clicked AND pointer is in
                a particular region, do: MOVE component
        

    -    load(enable)/unload(disable) individual FlightGear
        subsystems


Enable/disable is present for most subsystems.

Like I mentioned above: I got some doubts if they really DISABLE or merely HIDE ;-)


    -    use subsystems (video,network,sound ...) to do certain
        things - e.g.:

        ->    draw  images/animations within FlightGear's
            client area


Except movies, animations and images can be displayed and positioned already.

yes, ...using panel & instrument definition files - right ? :-)

-> play a certain sound


Is present.

...again, using XML-files I guess.

Maybe it would be really easier to create a particular class that makes
all loaded XML-files available as property tree nodes - that way, there
wouldn't be much re-writing necessary...


    -    do file handling stuff (probably using FlightGear's
        XML-routines)


This might need some attention.

I think the suggestion that I made above, could be used for that purpose.



That all done using XML (look in the FlightGear/data/gui subdirectory for the complete configuration of the menu layout).


okay, thanks again - but is it then also possible to *dynamically* alter
the menu, I mean not using XML definitions files ?


Hmm, I'm not sure about that ATM ...

That's actually what all my questions were all about: how do I these stings "on the fly" WITHOUT having to rely on existing Panel/Instrument definition files.

The Property-model that Nasal uses for its interfacing might be well
suited for that purpose I think.


Caution has been taken to make each property self explanatory (including what values to expect). This might not count for every single property though.

It might be a small advantage anyways, one cannot expect everybody (new FG users !) to understand what's meant by /sim/rendering/draw-otw=FALSE/TRUE - some little string that might reside in the same tree could easily add some more help.

Also, as PLIB/PUI lacks so far a decent treeview respectively listview
control, it might be useful to add a combobox for navigation
purposes (within the property tree) above the list control-
that way you could "quick jump" to certain nodes.

BTW: Are there any plans for the future to switch over to some more
powerful window manager than PUI (e.g.  FLTK) ?

Might be almost "easier" than adding the missing features to PUI ...

This is done by creating a new panel configuration file (see FlightGear/data/Docs/README.minipanel)


thanks, I will check it out - is it possible to create more than
one panel (on one screen) ?


I think it's possible, I'm just not sure if this is possible only for 3d cockpit layouts.

I didn't have success trying it out .


...but I would need these properties then to be used by the underlying
subsystem - which -I think- cannot be achieved by merely using Nasal ?


The configuration files tell a subsystem to which property it should react. So if you define an animation configuration file to use that property, and tell Nasal to alter that property, everything would be working just fine.



Some other questions:

        -       How about adding some basic font-formatting options
                to the PUI-XML handling, like doing:
                <legend><b>This is bold</b></legend>
                or
                <legend><font color="red">This is red</font></legend>
                a simple
                <legend><color="red">RED</color></legend> might of    
                course also do ...


- Is there any way to modify the default appeareance/behaviour of a dialog ? Like: setting the movable flag, transparency or color ?


- Is it possible to display a panel within a particular dialog ?

        -       Is there any way to customize buttons (e.g. attaching
                an image to a button) ?

        -       There doesn't seem to be CDATA support within
                panel/instrument definition files, using HTML entities
                worked, though.
        
        -       Is there way to define more than one dialog within one
                file ?

        -       How about adding keyboard bindings for the tab-key to
                the underlying PUI stuff in order to allow simple
                switching between controls ?

Thanks in advance !




---------- Boris




BTW: One minor "bug": if you try to set daytime when the game is paused, it doesn't have any effect - not even when you continue playing.

_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Reply via email to