Re: 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]>:

> 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
>

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