Re: Canvas UI Documentation

Why?

FG has historically used upper right close buttons... except for Canvas, where for some reason, all sence in UIX was ignored and they went on the left.

I would say the two options should be if you really want to make this configurable:

Default: Right close, left title
Option: Left close, center title (or left close and left title as Canvas has historically been)

That way UIX is preserved...

Having the title be in a consistent place is preferrable from a UIX perspective which is why centered titles is only done if there are lots of controls on the left - but one close button shouldn't be that, even Ubuntu when it used to have left caption buttons had left title.

--
Josh Davidson
________________________________
From: Frederic T. <[email protected]>
Sent: Sunday, June 7, 2026 14:04
To: FlightGear developers discussions <[email protected]>
Subject: Re: [Flightgear-devel] Canvas UI Documentation

Window title location will also be configurable (probably through the style), since it seems to be important for some people, but it will take time until we get the API / settings dialog done - I would be working on it already but I'm blocked by another MR concerning Canvas that needs to be merged first ...

Am So., 7. Juni 2026 um 20:56 Uhr schrieb Josh Davidson <[email protected]<mailto:[email protected]>>:
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]<mailto:[email protected]>>
Sent: Tuesday, May 12, 2026 02:36
To: FlightGear developers discussions <[email protected]<mailto:[email protected]>>
Subject: Re: [Flightgear-devel] Canvas UI Documentation



On 11 May 2026, at 15:42, Richard Harrison <[email protected]<mailto:[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]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

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