(1) SDL_PrivateAppActive()- The closest translation I can find is to
replace this with a pair of SDL_SendWindowEvent()
[SDL_WINDOWEVENT_HIDDEN/MINIMIZED and SDL_WINDOWEVENT_SHOWN/RESTORED].
Is this a correct replacement for all uses of this function? Did it do
(3) SDL_GetAppState() - Is there a replacement for this? I couldn’t
find any of the other supported platforms using this anymore.
Application-wide state made sense for 1.2, where you only ever have one
window. SDL 1.3 allows multiple windows, so we can’t have a single
global state for keyboard focus, etc.
You’ll notice that there’s a windowID member in most of the events in
SDL_events.h … that tells you which SDL window is “active”.
SDL_WindowEvent::event is used to tell you when focus, etc change, and
maps to the values you’ve found, like SDL_WINDOWEVENT_HIDDEN, etc. 1.2’s
"active" events map to some of these (but there is a more robust set of
events in 1.3). This is the closest mapping to what SDL 1.2 did.
You’re going to find it painful to migrate the 1.2 code to 1.3.
Internally, the video/audio/etc interfaces has changed dramatically.
You’ll probably find it easier to write it from scratch. Use an existing
1.3 target (like Windows or Mac OS X) as a template of what SDL wants
filled in, and use the 1.2 code as an idea of how to use the Haiku/BeOS
APIs to accomplish your goals. It’ll be much less struggle this way.
(2) SDL_TranslateUNICODE- I notice that this disappeared. Is unicode
even supported anymore, or should the conversion process always happen?
We cleaned this up for 1.3 (Unicode support is really bad in 1.2, to the
point of being unusable for many languages).
The way it worked in 1.2 is that you would turn on Unicode support with
SDL_EnableUNICODE(1), and then we’d give you Unicode characters attached
to keypresses. This doesn’t work for several reasons: some Unicode
characters need several keypresses to generate, and some keypresses
generate several characters at once…and lots of other issues that make
this messy. Not to mention that text input is sometimes completely
separate from keypresses (IME interfaces, etc).
1.3 does this right (I hope!), by making keypresses and text input
completely separate events…text might be generated by a keypress, but
it allows apps to basically treat the keyboard as a 101-button joystick
and get text input however the OS deems appropriate.
SDL_TextInputEvent is how these are delivered in 1.3. If Haiku only
supplies ASCII characters tied to keypresses, then this is a simple job
for you to hook up. If Haiku has a more robust text input system, then
you can scale up as appropriate.