1.3 Event source addition

I like the event loop of SDL and my only problem with 1.2 series is
that the Event subsystem is completly hidden and close. There is no
way to extends this part of the library that I know. It would really
interesting to be able to register new event source that are triggered
by SDL automatically.

Supposing I am using a networking library like SDL_Net I need to
construct my program the following

begin event loop

while there some SDL event do
if event is a mouse event …
if event is a keyboard event …

end

while there some Network event do

end

...

end

It would be cool to be able to register our own source of event using
an API call
similar to

struct SDLEventSource
{
void (pushEvents)(void userdata);
void* userdata;
};

SDL_EventRegisterSource(SDL_EventSource* source);

SDL_EventUnregisterSource(SDL_EventSource* source);

With such call we can integrate in a consistent way user defined event.

Hello !

I like the event loop of SDL and my only problem with 1.2 series is
that the Event subsystem is completly hidden and close. There is no way to
extends this part of the library that I know. It would really interesting
to be able to register new event source that are triggered by SDL
automatically.

Supposing I am using a networking library like SDL_Net I need to
construct my program the following

begin event loop

while there some SDL event do if event is a mouse event … if event is a
keyboard event … …
end

while there some Network event do …
end


end

It would be cool to be able to register our own source of event using
an API call similar to

struct SDLEventSource {
void (pushEvents)(void userdata); void* userdata; };

SDL_EventRegisterSource(SDL_EventSource* source);

SDL_EventUnregisterSource(SDL_EventSource* source);

With such call we can integrate in a consistent way user defined event.

Something like that would be really usefull,
for network coding but also other tasks
that needed to be synced in some way.

CU

Olivier Delannoy wrote:

I like the event loop of SDL and my only problem with 1.2 series is
that the Event subsystem is completly hidden and close. There is no
way to extends this part of the library that I know. It would really
interesting to be able to register new event source that are triggered
by SDL automatically.

seconded. fully agreed!

It would be cool to be able to register our own source of event using
an API call
similar to

struct SDLEventSource
{
void (pushEvents)(void userdata);
void* userdata;
};

SDL_EventRegisterSource(SDL_EventSource* source);

SDL_EventUnregisterSource(SDL_EventSource* source);

There are user events in SDL. Look for SDL_UserEvent in the doc.

The problem IMHO is that the event id (type) is not handled by SDL but
by the user. This way if you use two SDL libraries let’s say
SDL_lib1 and SDL_lib2 and they need user events you have to
tweak their source code in order to have non overlapping user events’ ids.

What I would like to see is something like this.

int SDL_RegisterUserEvent(); /* SDL returns the next free event id (e.g. SDL_USEREVENT)/
void SDL_UnRegisterUserEvent(int id) /
SDL unregister a previously given user event id */

if you try to unregister a system event (e.g. like mouseMove)
you should and will be shot.

I think the reason is done this way is for writing the switch case more easily

switch (event.type) {
case SDL_MOUSEMOTION:
.
.
.
case SDL_OTHERSYSTEMEVENT:
.
.
.

/* now the default should be like this /
default:
if (event.type == my_event_id_1) {
} else if (event.type == my_event_id_2) {
} else if (event.type == my_event_id_N) {
} else {
/
really unknown event */
}

  .bill

Hello !

int SDL_RegisterUserEvent(); /* SDL returns the next free event id (e.g.
SDL_USEREVENT)/
void SDL_UnRegisterUserEvent(int id) /
SDL unregister a previously given
user event id */

This is a good idea, as the Nr of events
may raise in upcomming SDL versions.

CU

I like the event loop of SDL and my only problem with 1.2 series is
that the Event subsystem is completly hidden and close. There is no
way to extends this part of the library that I know. It would really
interesting to be able to register new event source that are triggered
by SDL automatically.

What’s wrong with SDL_PushEvent()?

–ryan.

I second that. This is a feature that, IMHO, is missing from SDL 1.2
and is really required.On Thu, Jun 29, 2006 at 05:15:55PM +0200, Torsten Giebl wrote:

Hello !

int SDL_RegisterUserEvent(); /* SDL returns the next free event id (e.g.
SDL_USEREVENT)/
void SDL_UnRegisterUserEvent(int id) /
SDL unregister a previously given
user event id */

This is a good idea, as the Nr of events
may raise in upcomming SDL versions.


Steaphan Greene
Lecturer, Computer Science, Binghamton University
GPG public key: http://www.cs.binghamton.edu/~sgreene/gpg.key.txt
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20060629/b30ff7ef/attachment.pgp

PushEvent is nice and have to be use in the writing of a user defined
event source.

What is interesing with the ability of user defined event source is
letting SDL do the query when it’s needed. whether it use event thread
or not It does not add a lot of features it just help to make the
application more consistent. However I am not sure whether such thing
will be or not a "complex aspect of SDL requiring a lot of support on
the mailing list.On 6/29/06, Ryan C. Gordon wrote:

I like the event loop of SDL and my only problem with 1.2 series is
that the Event subsystem is completly hidden and close. There is no
way to extends this part of the library that I know. It would really
interesting to be able to register new event source that are triggered
by SDL automatically.

What’s wrong with SDL_PushEvent()?

–ryan.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

What is interesing with the ability of user defined event source is
letting SDL do the query when it’s needed.

I disagree. Formalizing this would add a lot of complexity, when you
could just change your program from this…

while (SDL_PollEvent(&e)) {

…to this…

checkNetwork(); // will call SDL_PushEvent() if needed.
while (SDL_PollEvent(&e)) { // will handle input and network events.

Now someone pointed out that there’s no way to prevent two libraries
from stepping on each other’s SDL_USEREVENTs, and that’s probably worth
fixing.

–ryan.

Ryan you are right, Adding personnalized source is not really needed
and will add a lot of complexity to the API for nothing. Thanks for
making it clear to me ;)On 6/30/06, Ryan C. Gordon wrote:

What is interesing with the ability of user defined event source is
letting SDL do the query when it’s needed.

I disagree. Formalizing this would add a lot of complexity, when you
could just change your program from this…

while (SDL_PollEvent(&e)) {

…to this…

checkNetwork(); // will call SDL_PushEvent() if needed.
while (SDL_PollEvent(&e)) { // will handle input and network events.

Now someone pointed out that there’s no way to prevent two libraries
from stepping on each other’s SDL_USEREVENTs, and that’s probably worth
fixing.

–ryan.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Now someone pointed out that there’s no way to prevent two libraries
from stepping on each other’s SDL_USEREVENTs, and that’s probably worth
fixing.

I agree. I added this to the 1.3 TODO list.

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment