Erik: you are causing some trouble over here, actually I didn't want to change the project's sourceforge name, but I appreciate you taking the time to make even another suggestion ;-)
Erik Hofman wrote:
Boris Koenig wrote:
I wouldn't have a problem, creating the authoring part of the application as an external application - but THEN I would need to be able to load FlightGear resources (aircraft/images/panels).
Ok. Lets start a *minimal* list of items that really are needed for this and skip the implementation part for now.
Okay, no problem - so you are now only talking of the "Player" part, right ?
This is what I think what would be needed (feel free to add your ideas).
okay, then I'll write down those things that I'd like to be able to do *interactively* using Nasal (i.e. don't want to rely on static files)
* A configurable, interactive menu system.
yes, this could easily be done by making the menu system available via a set of nodes in a corresponding property tree. *But this is currently NOT essential* - the menu(bar) itself is less likely to be changed that often - compared to other GUI elements.
So, I would not even add it to the "minimal list" right now - but IF it gets implemented it would make sense to add some kind of Nasal function to globally register Nasal based addons, that way I would not have to use a certain Menu named "FliteTutor" but rather could register FliteTutor to be loaded within a menu called "Addons" or something like that.
* The ability to load a set of "sheets", one after each other.
right, I have looked into the sources and think that should be also possible to be achieved using some specific node in a property tree (I gave some examples in one of my last eMails).
What I am now using - for testing purposes is:
/addons/FliteTutor/player/pages and /addons/FliteTutor/player/currentpage
While the former is an object that contains all necessary properties for a specific page, like:
pages[0]/position/x pages[0]/position/y etc.
And the latter property specifies which of the pages in player/pages is currently being displayed and hence should be read from the prop tree.
(Since, I don't yet know how to save & load this stuff using Nasal, I am setting it up each time in order to have some stuff available)
* Be able to add the following to these sheets: - Dynamic text at a static location (*)
...also DYNAMIC positioning - this could be also implemented using a specific node in the property tree.
text = setprop("/subsystem/../createTextWidget",1);
setprop(text,"position/x[0]",100);
setprop(text,"position/y[0]",200);and if possible, some simple formatting would also come in handy- like 2-3 different font sizes, BOLD and UNDERLINED text:
setprop(text,"font/format/size[0]","LARGE");
setprop(text,"font/format/bold[0]",1);This would probably already be sufficient regarding font handling.
- Static images (*)
yes, images won't get created on the fly, for any other dynamic image based contents I would make use of animations.
But it would be useful if I could not only specify their position in some XML file but rather do this dynamically - I think I did also provide a pseudo (nasal) code example in of my last mails.
Something like:
//Create Image
img = setprop("/subsystem/createImg[0]",1); //file
setprop(img,"filename[0]","sample.gif"); /*OPTIONALLY, it might be useful if I could directly provide a
binary or hex-encoded buffer to that function, in order to
enable storing of images WITHIN a XML file: <image type="JPEG" name="drawing">
0xFF,0xFF,0xFF,0xFF,0xFF .....
</imageAnd load this then by doing the following in Nasal:
readXML = func {
// function to retrieve contents of a section within a
// particular XML file
} data = readXML();
setprop(img,"buffer[0]",data); Even though that's not particularly elegant,
it would enable EASY exchange of modules, since
these wouldn't have any external dependencies
but could rather store all resources (e.g. images,
sound) within a module, EVEN if these are binary.
*/ //Position
setprop(img,"position/x[0]",100);
setprop(img,"position/y[0]",200); //Dimensions
setprop(img,"dimensions/x[0]",100);
setprop(img,"dimensions/y[0]",100);- Animated instruments that react to actions of the user(*)
yep, as well as being animated by the "player" - for illustrative purposes, but this isn't a problem I think, as I got an example to work already. But again, I don't want to rely on external XML files :-)
* Pop-up screens to guide a user.
right, I'm currently using a statically defined dialog with a fixed width, what I considered being useful AND powerful (also for FlightGear itself!) would be a template based dialog-creation.
So you would have standard dialog templates in /FlightGear/data/gui/dialogs
which can be used to create a template dialog, but then fill its contents with variable stuff.
It would already be sufficient to change the XML format to something like:
<text name="headline">
<x>100</x>
<y>200</y>
<label>TEST</label>
</text>
So that -optionally- each element is made accessible.That way, it SHOULD be possible to enable Nasal to access the template by doing something like this:
load-dlg-template = func {//XML processing } newDialog = load-dlg-template("template.xml");newDialog.headline.label="A different headline";
* Disable unwanted subsystems: - Out of the window view (* - including scenery loading?)
even though the latter is not mandatory right now, it would indeed be useful if there were some properties available to really individually enable/disable such systems, because it really doesn't make sense for all this stuff to be running in the background while the user sits in front a simple VOR animation and clicks through the lessons.
I don't yet know precisely WHICH subsystems exist or what their specific purpose is, but I think the CBT-screenshot that I published on the webpage illustrates quite well, that in some cases only few subsystems would need to be available (running).
Additionally, I think it would help making things more modular by providing the option to individually enable/disable certain subsystems.
- FDM (* - using the NULL FDM)
okay, thanks -didn't know that ! => should be mentioned !
(that's why I suggested adding an additinal commentary element to each node, describing its purpose and acceptable parameters, the latter could then even be put into a combo box or used to validate the users input)
- Multiplayer (*)
right, certainly absolutely not necessary (it would be nice if you could mention where to find the corresponding prop tree item)
- AI Traffic/Models/ATC (*) - Sound (*)
yes, disabled already these two - but especially sound may of course become necessary in some cases. This would then also require a certain Nasal function to play a particular sound - either specifiying a filename or maybe also a pointer to a binary array.
- Environment
don't know what for that one is, nor where to find it ?
Anything else (remember, this is the *absolute minimum*)?
yes, you didn't add "XML-file handling" (how exactly done, doesn't matter right now)
Also, I mentioned a couple of other useful changes such as changing the "movable flag" of a dialog, in order to en-/disable moving of certain dialogs.
Another thing that I need to access is the current size of the window or some other way to dynamically align the window elements (buttons, dialogs etc.) based on the current resolution:
Using the current static XML files, will mess up all my layout (fixed positions) when the FlightGear window is not maximized.
Though, Andy'S layouts MIGHT work instead (didn't yet try though), but I would want to do it using Nasal, anyway. So some kind of interface to Andy's layout mechanism via Nasal would be useful.
Also, it might make sense to change the transparency property of a dialog in some cases, as well as some basic background color support for a dialog.
On the other hand, some more control about PUI elements might come in handy.
But currently the most essential things are probably:
- dynamic handling of panels/dialogs using Nasal
(including dynamic population)
- some basic XML-support- some more advanced callback mechanism
WELL, SORRY: I just noticed, that my "short answer" got quite long
again ... also, I started again to concentrate on potential implementations - sorry for that:
Gotta go now, but I will write a short summary later and post it to the mailing list. That way I can also check my older postings and the webpage if we've forgotten anything.
But I really think, there are only 3-4 REALLY essential additions so that I can continue my efforts and make things dynamic.
The other stuff could also be added at a later time.
--------- Boris
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
