is much less unintrusive, and fixes crashes on most "retry" theme dialogs due
to reloading and resetting Lua and other things unexpectedly in the middle of
a screen load.
into one theme. I'm not sure why this was done originally, but it was probably
related to the ugly "fallback themes can fork Fallback" behavior that was
removed recently.
This is simpler, and reduces overhead in looking up theme metrics.
fallback was checked with the main theme, then each class fallback was checked
with the base theme, and so on.
Reverse this: check the class name with each theme, then check the class
fallback with each theme, and so on.
This is faster, since we only look up each class Fallback at most once, not
once per fallback theme, and groups together theme lookups (which may allow
further optimizations). More importantly, this matches the metric lookup
scheme.
This also makes more sense--if "ScreenWithMenuElements header" is overridden by
"ScreenMenu header" in the base theme, overriding "ScreenWithMenuElements header"
in a derived theme should change the same in the base theme (changing the
default) but not change the specialized "ScreenMenu header".
example, if a base theme had:
[Derived]
Fallback=Base1
[Base1]
A=1
and a derived theme had:
[Derived]
Fallback=Base2
[Base2]
then the lookup "Derived", "A" would find 1. This is confusing and inconsistent:
it means that the value of Derived::Fallback has two values, both Base1 and Base2,
and Base1 is only accessible by the internal metric lookup. Every metric should
have only one value; "Fallback=Base1" should be completely overridden here.
(This also reduces the difference between theme lookups and path lookups; path
lookups did not have this anomaly, as they did not have access to the extra Fallback
value.)
- RunAtExpressionS. Using @ to generate command lists is no longer allowed; it's
too expensive and clumsy, and is no longer needed.
- "::" for newlines. This isn't needed, since the string is a Lua expression;
use "\n".
- FontCharAliases::ReplaceMarkers. This only makes sense for settext calls.
(The latter two will still be supported by settext directly.)
Glenn Maynard