and "Foo/Bar/baz" exists, allow the case passed to be returned (foo/bar/baz).
ResolvePath is fairly expensive, and should only be used by file drivers
that actually need it.
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.)
Glenn Maynard