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:
0xFF,0xFF,0xFF,0xFF,0xFF .
And 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
dial
