20,741
edits
Canvas news: Difference between revisions
Jump to navigation
Jump to search
m
→2023: https://sourceforge.net/p/flightgear/mailman/message/37756261/
m (→2022) |
m (→2023: https://sourceforge.net/p/flightgear/mailman/message/37756261/) |
||
| Line 8: | Line 8: | ||
== 2023 == | == 2023 == | ||
<!-- | === PUI Emulation === | ||
01/2023: James slowly working on creating the pop-up menu and combo-box widgets [...] 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> | |||
One of the major things slowing down James' work on the popup-menu and combo box is time to restart the simulator for each change, he is looking for some solution to re-load the widget Nasal code independently. <ref><https://sourceforge.net/p/flightgear/mailman/message/37756183/</ref> | |||
James has done about 75% (hah!) of the C++ work to enable live reloading of modules this way, but unfortunately there are some code paths that would become crashy if you use the feature for the Canvas: because it would reference the ‘old’ (pre-reload) Nasal code, and not the new one, and therefore you’d get a weird mix of old and new, and then just crash the sim. To fix it properly I need to track down those places that store a reference to Canvas and give them a re-init method, so we don’t keep the stale references. | |||
The general non-fun-ness of that kind of debugging is why I’ve been making such slow progress on my PUI replacement widgets recently <ref>https://sourceforge.net/p/flightgear/mailman/message/37756263/</ref> | |||
== 2022 == | == 2022 == | ||