PUI: Difference between revisions

Jump to navigation Jump to search
2,018 bytes removed ,  19 January 2023
m
m (→‎Menubar: obsolete)
Line 103: Line 103:


The stubs for PopupMenu / Menu are already pushed, but the don’t have the style implementation, since James got stuck deciding how to handle the window for the menus <ref>https://sourceforge.net/p/flightgear/mailman/message/37756296/</ref>
The stubs for PopupMenu / Menu are already pushed, but the don’t have the style implementation, since James got stuck deciding how to handle the window for the menus <ref>https://sourceforge.net/p/flightgear/mailman/message/37756296/</ref>
=== Styling ===
We need to figure out the split of DefaultStyle.nas, but James is very keen to ensure we add a second style alongside the default, before we change much here.
Regarding styling, James is worried about us ending up putting code into the wrong side of the widget / Style split, if we don’t have a second alternative style implementation to ‘keep us honest’<ref>https://sourceforge.net/p/flightgear/mailman/message/37756178/</ref>
We really have two kinds of ’styles’
* tweaking margins, font sizes, colours etc should indeed be done in XML as you wrote : this is also analogous to styles in the PUI sense
* making radically different ways of presenting the same logical widgets: eg text label of checkbox in a different position relative to the button (of Surface vs Material vs iOS style, if you know web/mobile UIs)
For the second kind we would use a different Nasal style implementation and that’s the abstraction I think it is very important to maintain. It of course going to be a lot of work to make additional styles this way but it’s a very valuable feature to keep the possiblity, since it enables alternate UIs for user accessibility or different presentation modes such as VR.
What I don’t want to do is add lots of widgets assuming we only care about DefaultStyle.nas, and then have an impossible mountain to climb when someone needs an alternate Nasal style. We don’t have to make a complete alternate style now, but I don’t want to take shortcuts the make it impossible in the future. So I want to really think carefully about what is widget code and what is style code. <ref>https://sourceforge.net/p/flightgear/mailman/message/37756261/</ref>
Also, it is worth nothing that treating DefaultStyle.nas that way, is a straightforward mechanism to allow aircraft developers to customize their own styling for all sort of MFD purposes, without having to create complete widget sets from scratch - this is how Tom originally designed the whole thing, for his C130J.


=== Parser ===
=== Parser ===

Navigation menu