The same approach is taken for the menubar in FlightGear, which is also dynamically created using the file $FG_ROOT/gui/menubar.xml. So, depending on the level of "eyecandyness" that you envision, you might find PLIB's PUI sufficient or not, simply check out FlightGear and Atlas in order to get an impression of PUI's capabilities.On the other hand, actually keeping PUI would have the potential benefit of being able to re-use much of FlightGear's highly flexible GUI code (if you are interested in a dynamically configurable GUI): in large part, FlightGear itself makes no longer directly use of PLIB's GUI library PUI, rather FlightGear uses an wrapper that allows people/NON-PROGRAMMERS to easily create GUI elements (menubars, dialogs, controls) using an XML-oriented approach (similar to, but significantly less complex and feature-rich than Mozilla's XUL).That is, in order to add new GUI dialogs to FlightGear, you do not necessarily have to modify the (C++) source code, rather you can simply create an XML based dialog file (as explained in $FG_ROOT/Docs/README.gui, $FG_ROOT/Docs/README.layout) and put it under $FG_ROOT/gui/dialogs, afterwards the corresponding PUI dialog can be dynamically created at runtime. labels, buttons, text fields, check boxes, radio buttons), however it is highly portable (using OpenGL) and is known to work pretty well on all platforms supported by FlightGear. Atlas itself uses the same GUI library as FlightGear: PLIB's PUI:, this is a pretty simplistic widget library that contains only very basic controls (i.e. approach evaluation).Depending on the level of usability you envision, you might also want to have some sort of "overview" page, where all configurable properties are directly visible or at least accessible, so this is where some sort of GUI library/toolkit would come in. a "winds" button to configure the winds, a "temperature" button to modify the temperature etc.If you do intend to head towards a instructor station, most instructor stations for professional simulators also feature a profile view, this is something that Atlas does not yet support.So, Atlas might probably benefit from a corresponding vertical profile view in that case, so that the flight path can be depicted with regard to the underlying terrain, which would also add the possibility for instructors to do evaluations based on AGL altitude/terrain height (i.e. via some sort of history buffer) or later on, possibly even map such properties/macros to certain buttons/action, i.e. in order to configure environmental settings (such as winds, temperature, clouds etc.) or in order to change/reset the runway/position, daytime.FlightGear itself also supportes a so called "raw" mode for the specific purpose of automated telnet access, so that you do not have to do any complicated parsing when you set properties in order to fail a piece of equipment such as cockpit instruments, engines, flaps or the navcom.Of course, directly issuing telnet commands manually would probably become somewhat inconvenient for an instructor sooner or later, so you might want to sort of save frequently used properties (i.e. Besides, atlas itself is already written with portability in mind, so it would be straight forward to keep doing so.Basically, the only thing you might immediatley want to add would be an integrated telnet client (this can be accomplished using PLIB's netchat object), so that you can issue commands to FlightGear, i.e. I'm brand new to FlightGear, and>all these ideas seem like great starting points to work from.If you check out Atlas at you will see that it is indeed very well suited to be used as a framework for an instructor/obvserver station, where the mapping aspect is usually one of the more complex ones. >Thanks for being so helpful.Those are all great ideas,>especially the mapping aspect, we were kind of envisioning>something like that as well.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |