fgfs still has a lot of hard-coded dialogs, done by calling plib's
pu* functions directly. This may be justified in one or two cases
(property picker), but generally it's a bad idea:
- requires a lot of obscure low-level code
- no use of our excellent layouter
- dialogs aren't movable and block the rest of the gui
- dialogs don't accept gui theming colors
- changes are difficult, tests are cumbersome; both require recompilation
- currently not translateable (i18n)
But there's, of course, a reason why these dialogs do still not use
the 'new' XML gui: they contain variable widgets. Parts that should
be shown multiple times, depending on circumstances, and parts that
should sometimes be shown and at other times not.
Varying contents can easily be done with an intermediate solution:
(A) XML files that define the dialog skeleton, and (B) C++ code that
fills in the missing parts before displaying.
SGPropertyNode_ptr gui = (NewGUI *)globals->get_subsystem("gui");
SGPropertyNode_ptr dlg = gui->getDialog(dialog_name);
if (!dlg)
return; // no need to complain; getDialog() does this already
gui->closeDialog(dialog_name); // in case it's open ...
// edit the dlg property tree (see below)
gui->showDialog(dialog_name);
There are three ways to modify the XML skeleton from the C++ side:
(1) simply add the gui elements as properties (see README.gui)
(2) hide and unhide widgets/groups that are in the XML file
already (<hide> property)
(3) create copies from templates that are hidden in the XML file
(again <hide>). These templates can be whole widget subtrees
with arbitrary names. I prefer <*-template>, e.g. <group-template>
I've used (2) and (3) in the ATC files (see links below). There's, for
example, a <group-template> in the XML file atc_freq_display.xml,
which draws one line in the frequency table. I just make a copy for
each frequency line and unhide it. The template remains hidden all
the time.
One thing to consider is the identification of elements. It can be a
problem if one modifies "group[0]/text/label" in the code. Who says that
this will always be group #0? I've put <name> tags in some elements
and search, for example, the group that contains <name>frequency-list</name>.
But within such a named group I don't bother to identify further
elements by name. Generally, one has to make sure that C++ code and
XML definitions are in sync, but provisions can be made that this is
usually no issue.
Here's the conversion of ATCDialog.[ch]xx to this method. It
should do exactly what the old version did, plus: eliminate all the
disadvantages as listed above, and it even implements the TODO:
frequency-list quick-buttons for the nearest airports, sorted by
distance. :-)
To be applied in the src/ATC/ directory:
http://members.aon.at/mfranz/atc.diff.gz [6 kB]
To be unpacked in the $FG_ROOT/gui/dialogs directory:
http://members.aon.at/mfranz/atc-dialogs.tar.gz [1 kB]
Screenshot:
http://members.aon.at/mfranz/atc-dialogs.jpg [38 kB; maybe too dark]
Is this method acceptable? (I'd convert further hard-coded dialogs
in this style then.)
Is this patch acceptable for the ATC people? (I'd commit then, but
would probably make further minor changes. And if there are
special wishes, I'd consider that, too. For example, if you
don't like the quick-buttons, and want a <combo> instead.)
m.
_______________________________________________
Flightgear-devel mailing list
[email protected]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
