Message-ID: <5193F447.5010106 at charter.net>
Content-Type: text/plain; charset=“ISO-8859-1”; format=flowed
I think it was applied a few months back. Have you looked at the repo
code, and attempted to use the event hooks?
Not that I know of or from what I can see in the code. This whole
discussion came about because some people thought that what was in there
was enough, not realizing the requirements of the OS.
Technically speaking, the event filter system is enough (or at least
should be), but the events are most certainly needed as well.
Sam also mentioned that it was one of the outstanding things a little
while back, so that’s why I’m here again
Odd, I remember someone mentioning that they’ve already been using
SDL2 for Android for a while, which would imply that major stuff like
this does actually work. For example, Timodor was working on some
partially related stuff just a few days ago. Still, I didn’t see them
when I looked in the repo just now. Odd.
I didn’t make that clear enough, sorry. What I meant is these new
classes of events should never make it back to the stack regardless if
you pick them up or not, because doing them out-of-call will cause
really hard to diagnose crashes and for sure break your app. Idiot
proofing the API, basically, and it should be noted in the docs.
Uh, no, I picked up your meaning perfectly well, and was shooting it
down. “Idiot proofing” is a very direct translation of “Crippling”.
Anyone who actually makes this mistake would very quickly shoot
themselves in the foot, and there are few ways to learn faster than by
shooting yourself in the foot.
If the programmer doesn’t know how to do it right, then their users
will very quickly force them to learn.
For a point AGAINST, consider this: someone decides to create a
scripting-language binding for SDL. They don’t get to decide how the
scripting language works because it already exists, they just get to
connect it. They discover that they can handle all of the at-call-time
issues in the scripting engine, but they later need to pass the events
along to the script so that it can update it’s state to reflect the
changes that ALREADY happened. Do you want to stick the programmer
with marshaling the OS events to whichever thread, while maintaining
synchronization with the primary SDL event stack, or would it be
better to just let the callback say “stick this event on the stack”?
Remember, the callback and the event loop are very dissimilar. As long
as the requirements of those events are listed with the event’s
documentation, everything has been done that responsibly CAN be done.
I might as well throw out my two cents again. Let’s have another EVENT
type, say “SDL_APPLICATIONEVENT”, with sub-events ACTIVE,
BECOMING_ACTIVE, DEACTIVATE, GOING_TO_DEACTIVATE, LOW_MEMORY, and
I believe that at one point it was said that the mapping between iOS
and Android isn’t 100% for time-critical events. Regardless, this is
really platform-dependent stuff, so if the events don’t exist yet,
then they should be namespaced for the relevant operating system.> Date: Wed, 15 May 2013 16:47:03 -0400
From: Brian Barnes
To: sdl at lists.libsdl.org
Subject: Re: [SDL] SDL2 iOS Callbacks + Ray Tracer