Active Event Oddities

Hello,

I dunno if this is a bug, or whether there’s a good reason for this
but with SDL 1.2.5 under X11 when I dock a window I get 2 active events.
The first informs me of loss of keyboard focus and the second informs me
of loss of keyboard focus (again) and loss of visibility. So the first
event seems redundant.

This wouldn’t be so bad if it weren’t for another oddity. If I
call SDL_GetAppState in response to the first active event (the
one informing me of loss of keyboard focus) the loss of visibility
is reflected by this despite the fact that my app has not yet
seen a loss of visibility event.

Hopefully most peoples apps are sufficiently robust to cope with this
kind of thing, but in my experience (I do a lot of event driven
RT-Embedded stuff) this kind of wobbly semantics tends to be a cause of
bugs. By wobbly I mean you have to be darned careful if you provide 2
mechanisms for apps to know the current state of something (one event
driven whereby the app is informed of state changes and the second by
allowing direct state inspection). There is a danger that the info
derived by these two mechanisms is not consistent. In this case it
seems to me there is a danger that different parts of the same app may
think the window is visible and invisible at the same time.

So I would like to propose
1- Apps are never informed of the same state change twice (loss
of keyboard focus in this case).
2- The results returned by functions like SDL_GetAppState should
reflect the state that the app itself would see if it relied
on the event driven mechanism only. In this case if the app
has not been given a loss of visibility event as a result of
SDL_PollEvent or similar then SDL_GetAppState should show
the window as visible (even if it isn’t:-). It should not
be possible for apps to “short circuit” the event notification
mechanism by direct state inspection.

Perhaps not everybody would agree with this. Perhaps functions like
SDL_GetAppState are intended to enable apps to “short circuit” the
event notification mechanism. But in any case the true semantics
should be properly documented. If it’s intended that the results
of state inspection are not necessarily consistent with the state
that would be derived from event notification the SDL docs should
state this clearly IMHO. There seem to be other similar ambiguities
in keyboard and mouse states for example, but I haven’t yet
investigated enough to know what really goes on here :slight_smile:

Thanks–
Adrian Hey

Perhaps not everybody would agree with this. Perhaps functions like
SDL_GetAppState are intended to enable apps to “short circuit” the
event notification mechanism.

The events update the internal state of the library when they are added
to the event queue, so the direct inspection mechanism shows you what the
state would be if you processed all the events. This is intended, and
allows people to disable events if they just want instant state instead
of state change events. So, you really should either be using events
exclusively, or just use the events as a cue that the state has changed
and examine the state after you’ve finished draining the event queue.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Perhaps not everybody would agree with this. Perhaps functions like
SDL_GetAppState are intended to enable apps to “short circuit” the
event notification mechanism.

The events update the internal state of the library when they are added
to the event queue, so the direct inspection mechanism shows you what the
state would be if you processed all the events. This is intended, and
allows people to disable events if they just want instant state instead
of state change events.

Oh yes. I should’ve guessed I’d forgotten something.

So, you really should either be using events
exclusively,

Good idea. I think I’ll do that.

ThanksOn Tuesday 29 April 2003 18:32, Sam Lantinga wrote:

Adrian Hey