Re: Canvas UI Documentation

Josh Davidson <[email protected]> Sun, 7 Jun 2026 18:55:40 +0000
Newsgroups gmane.games.flightgear.devel
Message-ID <DS7PR07MB7734B194F6C3EFE572A94016CC1F2@DS7PR07MB7734.namprd07.prod.outlook.com>
Why is Canvas titlebar text centered now? We literally decided against this with the UI last time...

Why can't it just be left aligned and then you have as suggested that user selection between left/right side close button?

Which right side should be the default since that's the DWM default on most OS's (aside from Mac and some Linux DE's)...

Not sure why this decision was walked back on???

--
Josh Davidson
________________________________
From: James Turner <[email protected]>
Sent: Tuesday, May 12, 2026 02:36
To: FlightGear developers discussions <[email protected]>
Subject: Re: [Flightgear-devel] Canvas UI Documentation



On 11 May 2026, at 15:42, Richard Harrison <[email protected]> wrote:

This is where I disagree - we should make the XML capable of doing the most complex dialogs and extend it when it fails.  Of course in an ideal world we would have a dialog editor that you can run outside of the simulator to develop but that isn't likely to happen unless we someone writes one (hard) or we do something to parse the output of a another opensource GUI editor (e.g. Glade, QML Designer).

Declarative XML should be the first choice for lots of reasons

1. It can be validated against a schema in the editor and errors are caught before the sim starts.
2. it captures intent; the structure of the dialog is explicit and can be inspected independently of any code. XML tends to be readable.
3. The declarative form is durable in a way that procedural code is not. Nasal dialog code is all too often broken by unrelated stuff.
4. You can't autotest every possible option you have with procedural code - however we should be able to get a test suite that validates that the XML parser still works correctly (by inspecting the output tree against known good).

5. Lower barrier to entry - not everyone is good with Nasal
6. Error messages from the XML dialog parsers should be more useful that the errors you get writing Nasal

None of this should prevent modellers from using whatever they need to make their models work correctly;

I think that’s a good summary! I know not everyone will agree with all of it - and as we keep saying, in the end people can use what they want.

But yes, for Josh or anyone / everyone  else: *now* *is* a good time to start collecting feature requests or ‘things that have never worked’ about the GUI XML, under this epic:

https://gitlab.com/groups/flightgear/-/epics/1

… with the aim of doing what Richard hinted at above, of extending the XML until it’s (hopefully) compact, expressive, D-R-Y, etc. Thank to Florent the XML on next already supports translation keys for user-facing strings, BTW.

(I say it’s a good time, because the main C++ UI development is done, now it’s just a lot of refining and tweaking Nasal and adjusting APIs to add exactly these minor missing features…)

Kind regards,
James

_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel