(used by XmlFile) to depend on THEME, so use localized strings.
We may *always* want LocalizedString. One reason we may not
is if we start using the DynamicThemeMetric paradigm more.
That evaluates expressions when they're used, which allows
metrics to change dynamically. However, we may really not
want to do that for localized strings, since it would complicate
translation, so we may want to restrict localized strings to
pre-evaluation anyway.
code calls HOOKS->SetHasFocus when focus is lost or regained; user
code calls HOOKS->AppHasFocus as needed. This moves the very
simple task of remembering focus to ArchHooks, and removes a
few annoying dependencies on StepMania.cpp. (That's the highest-
level code there is, so very few things should depend on it.)
The original design of HOOKS is to be a place where portable
code calls to do platform-specific things, not to be a place
for nonportable code to call to do generic things. These
state calls (SetHasFocus, SetToggleWindowed, SetUserQuit) don't
quite fit that. But there's currently no better place to put
these, and they're just as low-level, so it's not really a
layering violation. Hmm.
(This also eliminates GameLoop's dependency on StepMania.cpp. Keeping
GL.cpp independent of SM.cpp is helpful. It's not as useful to
split apart two files, if the two files are cross-dependent anyway;
you still have to know how both files work in order to understand
either of them.)
sending a corresponding release event. This results in "stuck
keys" in InputFilter's image of the devices. We've worked around
this by forcibly releasing all keys when focus is lost, but it's
still a bug in the input driver. Fix this, by releasing devices
when we discard events.
setting. It's usually tied to the screen resolution (will usually
need readjustment anyway if the resolution changes). Treat the
values as pixels, as if we were using glViewport to do this.
(Reduces dependencies on ScreenDimensions.h, and we don't need
to worry about calling ChangeCentering when the theme changes.)
in the editor, to avoid confusion with the SM_Success message sent when
Prompt pops itself.
Merge completion prompts in home and full mode. Only show a full
ScreenPrompt if we're about to exit the screen.
- This reduces the number of types associated with input; adding a
distinct input type doesn't introduce a whole new enumerated type
and related functions.
- Special handling for different devices is needed less often. If you
want to respond to an F1 press, simply check for KEY_F1; the device
type doesn't really matter (though it'll usually be a keyboard).
- This allows cleaner support for generalized USB devices. While they're
usually of the traditional classes (keyboard, joystick) with associated
inputs, they don't have to be.
- Forced casts between parallel types can be removed, and weakly-specified
variables (ints instead of the enum type) can be fixed.
Some things that might have been merged havn't; for example, arrow keys
on a keyboard (KEY_UP) are still distinct from axes on a joystick (JOY_UP).
These may or may not be merged in the future.
Some were: removed PUMP_ symbols. Treat them as generic buttons, and just
give them names with GetDeviceSpecificInputString. It's not worth
introducing more special names for something only used in one place.
the standard had already been released. What's the point of having
standard language abbreviations if they're subject to change?
"Annex B" in ISO 639-1:2001 (over a decade later, if that's a year) says
"The changes were publicised, but they have not been included in printed
versions of ISO 639." The first google hit for ISO-639 still makes no mention
of these changes (http://www.w3.org/WAI/ER/IG/ert/iso639.htm). That rules.
Remove "XS?"; as far as I can tell that's just an error in the "native language"
page.
Glenn Maynard