mostly useful for pointing casual users to drivers, but any URLs
we give them will just go out of date, and 404s don't help people.
It's also too heavyweight to be done in ArchHooks; aim to not use
anything in it that we don't want to always include.
(I'm sort of undecided about this. This definitely needs to be out
of HOOKS; it could be moved to GraphicsWindow. It's potentially
useful, in theory, but it'd be a major hassle to maintain and always
be incomplete. Since it's only used for one ancient card and has
never been used for anything else, I'm just removing it for now.)
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.
Steve Checkoway