Board index FlightGear Development

GUI Styles vastly ignored, Why ?  Topic is solved

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

GUI Styles vastly ignored, Why ?

Postby mhab » Thu Feb 26, 2015 11:59 am

Hello

On my journey through FG world I learned there is a possibility to have different GUI styles (as of FG 2.6)
Two different GUI styles come predefined with FG.
See: Howto:Create a custom GUI style for details.

For a while there was a Menu entry in Debug menu for cycling through the available styles (utilizing: gui.nextStyle(); function)
This was removed since FG 2.14 or so.
I guess this may be because the majority of FG users only use the default Linux type style ?

My point:
    - I use the alternative Windows like style
    - Several dialogs in FG are designed poorly for the alternative style !
    e.g. the layout expects the default style and ignores the possible use of e.g another font.
    - This leads to overlapping text and even controls
    - Some dialogs are defined so "hard-coded", that the alternative style cannot even use other colors
    e.g. the FG 3.4 new map-canvas.xml ignores alternative styles completely, for font and color design

I know at least 6-8 dialogs which use a poor or incompatible layout for alternative styles.

My question:
Are several FG developers just ignorant for supporting more flexible layouts or is the official intention to eliminate alternative styles completely ?

Mike-DE
mhab
 
Posts: 418
Joined: Thu Apr 18, 2013 11:59 pm
Callsign: D-MIKE
Version: 2020.3.4
OS: Win10

Re: GUI Styles vastly ignored, Why ?

Postby stuart » Thu Feb 26, 2015 12:26 pm

Hi Mike,

I've done quite a bit of work over the years on the various dialogs within FlightGear.

I don't think it's so much ignorance, more that the XML GUI controls are very limited, particularly when trying to get a sensible layout that will work within low screen resolutions. So I've ended up working the layouts with the default UI style, and not tested with other GUI styles.

I don't know whether Canvas support the GUI styles or not.

You should be aware that there are various developments in progress that may affect the UI, including a Web-based interface.

I don't think there's an official intention to eliminate alternatives styles, but I think it's very likely that the XML-based GUIs will be deprecated within the next couple of releases.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: GUI Styles vastly ignored, Why ?

Postby mhab » Thu Feb 26, 2015 7:32 pm

Hello Stuart

Thanks for this info.
Let me say I appreciate your work, that I came across many times. :D

What I don't like about FG strategy is sayings like these: In future - whatever how long it will take - there will be a somewhat better and new approach, so we leave everything as it is.

I spent an hour on the map.xml and map-canvas.xml dialogs and - o wonder - now they layout well in both GUI styles.

So here is some advice on what to avoid, in order to get proper layout more flexible

    - avoid <pref-width>xxx</pref-width> except for the rare case you need to really make sure the size
    - don't use <color>...</color> to fix a color, as it will be a bad choice with alternative style in most cases (like in checklists)

Most of the time the whole thing is fixed just by changing the above two.
In map/map-canvas I had to add a <halign>left</halign> to each checkbox and that did it.

Remark:
If git wouldn't be such a hassle, I would willingly fix the dialogs.

Mike-DE
mhab
 
Posts: 418
Joined: Thu Apr 18, 2013 11:59 pm
Callsign: D-MIKE
Version: 2020.3.4
OS: Win10

Re: GUI Styles vastly ignored, Why ?

Postby wlbragg » Thu Feb 26, 2015 8:51 pm

mhab wrote in Thu Feb 26, 2015 7:32 pm:Hello Stuart
Remark:
If git wouldn't be such a hassle, I would willingly fix the dialogs.
stuart wrote in Thu Feb 26, 2015 12:26 pm:Hi Mike,
I think it's very likely that the XML-based GUIs will be deprecated within the next couple of releases.


Mike,
I feel your pain. I've been troubled by the GUI since we entered the computer age. I too wanted to contribute to bring it into the 21st Century.
This is one area that it seems there may be some competing interests, or at least overlapping and it is unclear as to what will come out the other side, at least to us uniformed users.
If there is a solid road map, now would be a good time for those who are in the know to spell it out.

Not knowing how long or if any GUI changes will be implemented, if your willing to do the work and take the chance that it is in vain and your only other hesitation is GIT, I'd be more than happy to submit a commit request on your behalf whenever you are ready.
All I can guarantee though is that the request will be submitted.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7587
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: GUI Styles vastly ignored, Why ?

Postby stuart » Thu Feb 26, 2015 9:01 pm

Hi Mike-DE,

If you'd like to submit changes, I'd be more than happy to commit them. I shouldn't be discouraging about making things better - sorry. Certainly if you've made improvements we should get them into git so everyone can benefit.

wlbragg - I don't think there's a solid road map - just a lot of ideas and some development happening.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: GUI Styles vastly ignored, Why ?

Postby Hooray » Thu Feb 26, 2015 9:38 pm

Many features that were originally added by core developers who are no longer actively involved, tend to stagnate sooner or later - if I remember correctly, it was mfranz (Melchior Franz) who came up with style-able GUI themes by mapping PUI attributes to properties - that was many years ago, long before the recent interest in revamping the FlightGear GUI.
For features to survive, they need to be well-documented, come with examples and use-cases, but even active maintenance/oversight may be required once in a while. Given mfranz's departure from FG matters, several of his contributions have suffered quite a bit in the meantime - which can be particularly seen by the quality of Nasal contributions added to $FG_ROOT.

Having been involved in both the Canvas GUI effort and the creation/porting of the map-canvas.xml dialog, let me clarify a few things:

  • the Canvas GUI itself doesn't currently support PUI/XML-based styling, it is using a much more flexible styling system based on CSS concepts
  • the map-canvas.xml dialog however is a conventional PUI XML dialog with an embedded Canvas widget, so it is trivial to support legacy styles there (as you figured out meanwhile)
  • PUI has been proven to be causing performance issues even when just being rendered/shown - so we were hoping to re-implement the map-canvas.xml dialog using a native Canvas dialog
  • like Stuart said, there are several overlapping efforts at modernizing FlightGear's GUI (do a forum search for "Qt5" to learn more) - none of those have announced a feasible concept for dealing with the existing plethora of existing legacy dialogs, intended to be used from inside the simulator (same process, same window) - especially long-term maintenance to prevent diverging UI front-ends and different capabilities, i.e. 5+ years from now (just look at the plethora of GUI front-ends supporting different features/platforms).
  • the Canvas GUI however can deal with loading existing legacy dialogs by procedurally turning them into canvas widgets, we have seen protoype code doing this sort of thing already - i.e. a "button" or "checkbox" PropertyList element (as per README.gui) is mapped to a factory helper that looks up the corresponding Canvas creation routine - which transparently supports existing GUI files, without them having to be ported/rewritten from scratch manually
  • equally, people could keep using the old/familiar markup for just adding simple dialogs
  • internally, legacy dialogs are managed using a few fgcommands which can be trivially mapped to Nasal/Canvas space using addCommand() to build Canvas GUI widgets/dialogs procedurally from existing legacy specs
  • this is what the original plan used to be, as it was discussed on the devel list in 2012/2013 - so there is a clear plan to handle these use-cases using the original Canvas GUI approach

Meanwhile, some things have changed mainly because of people starting from scratch with very different ideas and concepts - but none of that is generally bad, especially when taking into account that the UI has been de-facto unmaintained for the last 10 years - so these are pretty much "exciting" times for people interested in a modern FG GUI :D

Equally, we've had long-standing issues like supporting sim-wide reset/re-init saving/loading flights at run-time or getting rid of having 15+ redundant GUI launchers, and moving to online/live-deployment of scenery/aircraft and other resources.
All of these issues are currently being addressed - so "change" per se is not generally a bad thing, in fact, you could argue that many of these efforts have been overdue far too long.

In summary, I think you should go ahead and get your changes submitted/committed - simply because the FG community is hugely chaotic and there's usually more disagreement than actual development going on unfortunately - the very instant someone comes up with with a new feature/idea or piece of code, there are suddenly 20+ people who all remembered how to "design" things properly from their CS 101 days in college ... so, people have a tendency to disagree with something long before they have a better alternative available.

From "our" (canvas/Canvas GUI/MapStructure and map-canvas.xml) side, I can only re-iterate that the mid-term idea was to replace map-canvas.xml using a native Canvas dialog instead (no PUI at all, and no legacy styling, but full Canvas UI styling instead) - mainly because PUI has been demonstrated to cause considerable frame spacing issues even with just the menubar shown, while Canvas performs much better.

Concerning the other two UI efforts going on (web UI and Qt5), there remains one issue that need to be addressed in order for either of those to be considered a viable alternative/replacement for PUI or the Canvas UI (a GUI running inside the main FG process/window): dependencies i.e. accepting WebKit, and especially, Qt5, as build-time dependencies for all platforms would need to be thoroughly discussed on the devel list to arrive at some consensus. And looking at how divided the FG community was in early 2006 when Mathias started adding OSG, or when Tim started adding boost - it is foreseeable that consensus will be hard to establish ...

In the meantime, you can be pretty sure that PUI is going stay around as long as the Canvas UI isn't yet sufficiently complete, at which point it would be phased out probably, but transparently so - i.e. providing a scripting space framework to maintain parity with the legacy set of GUI files, including dialogs, widgets and styles.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: GUI Styles vastly ignored, Why ?

Postby mhab » Sat Mar 07, 2015 2:49 pm

Hello all

Thanks for all the info, esp. thanks to Hooray

Just as a short status info: I worked through a lot of dialogs and have already passed this to Stuart, who is so kind to help me out with my Git problems.
I hope this will be an improvement for consistency in layout and writing (e.g. CamelCase for all texts) and an improvement in the GUI :D

Mike-DE
mhab
 
Posts: 418
Joined: Thu Apr 18, 2013 11:59 pm
Callsign: D-MIKE
Version: 2020.3.4
OS: Win10

Re: GUI Styles vastly ignored, Why ?

Postby wlbragg » Sat Mar 07, 2015 3:00 pm

Thank you mhab and Stuart, this is a long time coming. I can't wait to see the results. :D back at ya!
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7587
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: GUI Styles vastly ignored, Why ?

Postby Hooray » Sat Mar 07, 2015 6:14 pm

When I prototyped map-canvas.xml I simply copied the original map.xml dialog and adapted that, which happened to lack support for styling back then - so that's how we arrived at both dialogs lacking support for the legacy styling system. I guess it would be possible to use xmlstarlet (or some other XML processing tool/script) to automagically review existing dialogs and track down any remaining issues, as long as you can come up with heuristics - e.g. certain tags/attributes being present/missing.
In fact, it would be trivial to use a few lines of Nasal to automatically review/validate such dialogs before showing them using the corresponding fgcommands.
So if people agree that this would be worthwhile, I can provide pointers and code snippets to use heuristics to automatically track down problematic GUI dialogs and display corresponding log messages.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: GUI Styles vastly ignored, Why ?  

Postby mhab » Mon May 04, 2015 10:28 pm

Hello

Short notice: Stuart has finally reviewed and comitted all the GUI enhancements I had worked through. Many thanks to him for helping out on this.
It had been more than I first thought of, but it will be in FG 3.6

Mike-DE
mhab
 
Posts: 418
Joined: Thu Apr 18, 2013 11:59 pm
Callsign: D-MIKE
Version: 2020.3.4
OS: Win10


Return to Development

Who is online

Users browsing this forum: No registered users and 12 guests