SDL 2.0 API stabilization

John6 · March 3, 2013, 5:47am

The state that is affected is the mouse state. SDL maintains mouse state in a
global variable. It represents the current state of all the mouse info, x,y,
delta, button states, cursor info, etc. Whenever a mouse event is about to be
placed onto the queue, the global mouse state is updated to match the event.

The specific issue is that the global mouse state is updated whenever a mouse
event is posted, whether or not it is a simulated event. For example, when a
touch event is created, a simulated mouse event is also generated, and this
alters the global mouse state. Then the simulated event is placed onto the
queue, where it is delivered to the application. Applications can discard the
event by checking for evt.mouse.which==SDL_TOUCH_MOUSEID, but they cannot
discard the global state change that was already committed before the event was
delivered.On 03/03/2013 12:21 AM, Sik the hedgehog wrote:

What states could be affected? May want to narrow down the specific
issues that could arise before trying to discuss what to do about it.

2013/3/3, John <@John6>:

Does the mouse state become affected by delivery of the simulated events?
i.e.,
will touch events now alter the mouse state?

On 03/03/2013 12:09 AM, Sik the hedgehog wrote:

Yeah, that seems better. I realized later that SDL_INIT_TOUCH would
result in programs using SDL_INIT_EVERYTHING to not get emulated touch
input, but I was away by then (honestly using SDL_INIT_EVERYTHING
isn’t a good idea in the first place, but eh)

2013/3/3, Sam Lantinga :

You can now tell if a mouse event was simulated by touch input. The
mouse
event has a new ‘which’ field and is set to the value
SDL_TOUCH_MOUSEID.

I talked it over with Ryan and this was the best solution which didn’t
involve unexpected behavior changes and still allowed smart applications
to
do the right thing.

Cheers!

On Sat, Mar 2, 2013 at 10:38 AM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

So basically SDL_INIT_TOUCH? (if a program acknowledges it supports
touch there isn’t any reason to emulate touch events)

2013/3/2, Sam Lantinga :

I agree, this needs to be addressed.

Another option is to default touch events off, and deliver mouse
events
if
they are off, and touch events if they are enabled.

On Sat, Mar 2, 2013 at 9:50 AM, John <@John6> wrote:

The android duplicate event issue needs to be addressed before SDL2
is
stable on Android. The patch is in the ticket:
http://bugzilla.libsdl.org/**show_bug.cgi?id=1713<
simulated mouse events duplicate touch events · Issue #755 · libsdl-org/SDL · GitHub>

The motivation is that developers cannot currently write a portable
event
loop in SDL2 if they want to support touch events.

On 02/18/2013 02:19 AM, Sam Lantinga wrote:

We’re on the road to release for SDL 2.0.

To that end, most of the existing APIs are stable, and we’ll only
change
them if
it’s critical.
There are a few things which are still being considered, such as the
iOS
event
handling, and touch/mouse event semantics, but by and large the API
is
set for
release.

Please report bugs which are affecting you in the current snapshot:
http://www.libsdl.org/tmp/SDL-**2.0.zip<
http://www.libsdl.org/tmp/SDL-2.0.zip>

If anyone wants to fix anything currently in bugzilla, they are more
than
welcome:
http://bugzilla.libsdl.org http://bugzilla.libsdl.org/

Cheers!
–Sam

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org<
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org<
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Sik_the_hedgehog · March 3, 2013, 5:59am

I was asking specifically which parts of the mouse state get affected,
e.g. position, buttons, etc.

I guess it isn’t much of a problem if you’re just checking events and
keep track of the status on your own (which I had to do to work around
a bug regarding alt+tab), but I assume it can be a big issue if you
query the mouse state directly (which also won’t let you know if touch
emulation is in place…).

2013/3/3, John :> The state that is affected is the mouse state. SDL maintains mouse state in

a
global variable. It represents the current state of all the mouse info, x,y,

delta, button states, cursor info, etc. Whenever a mouse event is about to
be
placed onto the queue, the global mouse state is updated to match the
event.

The specific issue is that the global mouse state is updated whenever a
mouse
event is posted, whether or not it is a simulated event. For example, when a

touch event is created, a simulated mouse event is also generated, and this

alters the global mouse state. Then the simulated event is placed onto the
queue, where it is delivered to the application. Applications can discard
the
event by checking for evt.mouse.which==SDL_TOUCH_MOUSEID, but they cannot
discard the global state change that was already committed before the event
was
delivered.

On 03/03/2013 12:21 AM, Sik the hedgehog wrote:

What states could be affected? May want to narrow down the specific
issues that could arise before trying to discuss what to do about it.

2013/3/3, John :

Does the mouse state become affected by delivery of the simulated
events?
i.e.,
will touch events now alter the mouse state?

On 03/03/2013 12:09 AM, Sik the hedgehog wrote:

Yeah, that seems better. I realized later that SDL_INIT_TOUCH would
result in programs using SDL_INIT_EVERYTHING to not get emulated touch
input, but I was away by then (honestly using SDL_INIT_EVERYTHING
isn’t a good idea in the first place, but eh)

2013/3/3, Sam Lantinga :

You can now tell if a mouse event was simulated by touch input. The
mouse
event has a new ‘which’ field and is set to the value
SDL_TOUCH_MOUSEID.

I talked it over with Ryan and this was the best solution which didn’t
involve unexpected behavior changes and still allowed smart
applications
to
do the right thing.

Cheers!

On Sat, Mar 2, 2013 at 10:38 AM, Sik the hedgehog < @Sik_the_hedgehog> wrote:

So basically SDL_INIT_TOUCH? (if a program acknowledges it supports
touch there isn’t any reason to emulate touch events)

2013/3/2, Sam Lantinga :

I agree, this needs to be addressed.

Another option is to default touch events off, and deliver mouse
events
if
they are off, and touch events if they are enabled.

On Sat, Mar 2, 2013 at 9:50 AM, John wrote:

The android duplicate event issue needs to be addressed before SDL2
is
stable on Android. The patch is in the ticket:
http://bugzilla.libsdl.org/**show_bug.cgi?id=1713<
simulated mouse events duplicate touch events · Issue #755 · libsdl-org/SDL · GitHub>

The motivation is that developers cannot currently write a portable
event
loop in SDL2 if they want to support touch events.

On 02/18/2013 02:19 AM, Sam Lantinga wrote:

We’re on the road to release for SDL 2.0.

To that end, most of the existing APIs are stable, and we’ll only
change
them if
it’s critical.
There are a few things which are still being considered, such as
the
iOS
event
handling, and touch/mouse event semantics, but by and large the
API
is
set for
release.

Please report bugs which are affecting you in the current
snapshot:
http://www.libsdl.org/tmp/SDL-**2.0.zip<
http://www.libsdl.org/tmp/SDL-2.0.zip>

If anyone wants to fix anything currently in bugzilla, they are
more
than
welcome:
http://bugzilla.libsdl.org http://bugzilla.libsdl.org/

Cheers!
–Sam

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org<
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org<
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

John6 · March 3, 2013, 6:57am

These global fields (of the SDL_mouse struct) are affected: x,y, last_x, last_y,
xdelta, ydelta, buttonstate. Those fields, in turn, are used to generate the
event. See SDL_SendMouseButton() and SDL_SendMouseMotion() in
“src/events/SDL_mouse.c”.On 03/03/2013 12:59 AM, Sik the hedgehog wrote:

I was asking specifically which parts of the mouse state get affected,
e.g. position, buttons, etc.

I guess it isn’t much of a problem if you’re just checking events and
keep track of the status on your own (which I had to do to work around
a bug regarding alt+tab), but I assume it can be a big issue if you
query the mouse state directly (which also won’t let you know if touch
emulation is in place…).

2013/3/3, John <@John6>:
The state that is affected is the mouse state. SDL maintains mouse state in
a
global variable. It represents the current state of all the mouse info, x,y,

delta, button states, cursor info, etc. Whenever a mouse event is about to
be
placed onto the queue, the global mouse state is updated to match the
event.

The specific issue is that the global mouse state is updated whenever a
mouse
event is posted, whether or not it is a simulated event. For example, when a

touch event is created, a simulated mouse event is also generated, and this

alters the global mouse state. Then the simulated event is placed onto the
queue, where it is delivered to the application. Applications can discard
the
event by checking for evt.mouse.which==SDL_TOUCH_MOUSEID, but they cannot
discard the global state change that was already committed before the event
was
delivered.

On 03/03/2013 12:21 AM, Sik the hedgehog wrote:
What states could be affected? May want to narrow down the specific
issues that could arise before trying to discuss what to do about it.

2013/3/3, John <@John6>:
Does the mouse state become affected by delivery of the simulated
events?
i.e.,
will touch events now alter the mouse state?

On 03/03/2013 12:09 AM, Sik the hedgehog wrote:
Yeah, that seems better. I realized later that SDL_INIT_TOUCH would
result in programs using SDL_INIT_EVERYTHING to not get emulated touch
input, but I was away by then (honestly using SDL_INIT_EVERYTHING
isn’t a good idea in the first place, but eh)

2013/3/3, Sam Lantinga :
You can now tell if a mouse event was simulated by touch input. The
mouse
event has a new ‘which’ field and is set to the value
SDL_TOUCH_MOUSEID.

I talked it over with Ryan and this was the best solution which didn’t
involve unexpected behavior changes and still allowed smart
applications
to
do the right thing.

Cheers!

On Sat, Mar 2, 2013 at 10:38 AM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:
So basically SDL_INIT_TOUCH? (if a program acknowledges it supports
touch there isn’t any reason to emulate touch events)

2013/3/2, Sam Lantinga :
I agree, this needs to be addressed.

Another option is to default touch events off, and deliver mouse
events
if
they are off, and touch events if they are enabled.

On Sat, Mar 2, 2013 at 9:50 AM, John <@John6> wrote:
The android duplicate event issue needs to be addressed before SDL2
is
stable on Android. The patch is in the ticket:
http://bugzilla.libsdl.org/**show_bug.cgi?id=1713<
simulated mouse events duplicate touch events · Issue #755 · libsdl-org/SDL · GitHub>

The motivation is that developers cannot currently write a portable
event
loop in SDL2 if they want to support touch events.

On 02/18/2013 02:19 AM, Sam Lantinga wrote:
We’re on the road to release for SDL 2.0.

To that end, most of the existing APIs are stable, and we’ll only
change
them if
it’s critical.
There are a few things which are still being considered, such as
the
iOS
event
handling, and touch/mouse event semantics, but by and large the
API
is
set for
release.

Please report bugs which are affecting you in the current
snapshot:
http://www.libsdl.org/tmp/SDL-**2.0.zip<
http://www.libsdl.org/tmp/SDL-2.0.zip>

If anyone wants to fix anything currently in bugzilla, they are
more
than
welcome:
http://bugzilla.libsdl.org http://bugzilla.libsdl.org/

Cheers!
–Sam

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org<
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>
______________________________**_________________
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org<
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org>
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

slouken · March 3, 2013, 7:28am

They currently do, but in the long term we may want to separate them, or
add a hint to prevent the mouse event simulation.On Sat, Mar 2, 2013 at 9:19 PM, John wrote:

Does the mouse state become affected by delivery of the simulated events?
i.e., will touch events now alter the mouse state?

On 03/03/2013 12:09 AM, Sik the hedgehog wrote:

Yeah, that seems better. I realized later that SDL_INIT_TOUCH would
result in programs using SDL_INIT_EVERYTHING to not get emulated touch
input, but I was away by then (honestly using SDL_INIT_EVERYTHING
isn’t a good idea in the first place, but eh)

2013/3/3, Sam Lantinga <@slouken>:

You can now tell if a mouse event was simulated by touch input. The
mouse
event has a new ‘which’ field and is set to the value SDL_TOUCH_MOUSEID.

I talked it over with Ryan and this was the best solution which didn’t
involve unexpected behavior changes and still allowed smart applications
to
do the right thing.

Cheers!

On Sat, Mar 2, 2013 at 10:38 AM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:

So basically SDL_INIT_TOUCH? (if a program acknowledges it supports

touch there isn’t any reason to emulate touch events)

2013/3/2, Sam Lantinga <@slouken>:

I agree, this needs to be addressed.

Another option is to default touch events off, and deliver mouse events

if

they are off, and touch events if they are enabled.

On Sat, Mar 2, 2013 at 9:50 AM, John wrote:

The android duplicate event issue needs to be addressed before SDL2 is

stable on Android. The patch is in the ticket:
http://bugzilla.libsdl.org/****show_bug.cgi?id=1713 http://bugzilla.libsdl.org/**show_bug.cgi?id=1713
<

http://bugzilla.libsdl.org/**show_bug.cgi?id=1713 http://bugzilla.libsdl.org/show_bug.cgi?id=1713

The motivation is that developers cannot currently write a portable

event

loop in SDL2 if they want to support touch events.

On 02/18/2013 02:19 AM, Sam Lantinga wrote:

We’re on the road to release for SDL 2.0.

To that end, most of the existing APIs are stable, and we’ll only

change

them if

it’s critical.
There are a few things which are still being considered, such as the

iOS

event

handling, and touch/mouse event semantics, but by and large the API
is
set for
release.

Please report bugs which are affecting you in the current snapshot:
http://www.libsdl.org/tmp/SDL-****2.0.zip http://www.libsdl.org/tmp/SDL-**2.0.zip
<

http://www.libsdl.org/tmp/SDL-**2.0.zip http://www.libsdl.org/tmp/SDL-2.0.zip

If anyone wants to fix anything currently in bugzilla, they are more
than
welcome:
http://bugzilla.libsdl.org http://bugzilla.libsdl.org/

Cheers!
–Sam

_____________****
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/****listinfo.cgi/sdl-libsdl.org http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org
<

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________****

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/****listinfo.cgi/sdl-libsdl.org http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org
<

http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_____________**
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/**listinfo.cgi/sdl-libsdl.org http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

icculus · March 4, 2013, 3:21am

Actually, that’s a good point: should we nuke SDL_INIT_EVERYTHING from
SDL 2.0?

I mean, if we add a new subsystem, and someone has written…

if (SDL_Init(SDL_INIT_EVERYTHING) == -1)
    exit(1);

…then their working program might break when they don’t have some
exotic new functionality on their platform.

–ryan.On 3/3/13 12:09 AM, Sik the hedgehog wrote:

Yeah, that seems better. I realized later that SDL_INIT_TOUCH would
result in programs using SDL_INIT_EVERYTHING to not get emulated touch
input, but I was away by then (honestly using SDL_INIT_EVERYTHING
isn’t a good idea in the first place, but eh)

icculus · March 4, 2013, 3:23am

Actually, that’s a good point: should we nuke SDL_INIT_EVERYTHING from
SDL 2.0?

…while I’m thinking about it, should we roll SDL_INIT_HAPTIC and
SDL_INIT_GAMECONTROLLER into SDL_INIT_JOYSTICK?

–ryan.

Sik_the_hedgehog · March 4, 2013, 3:46am

Personally yeah, merging those makes sense. I think haptic may require
separate APIs on some platforms but in the worst case just make the
haptic functions return an error and be done with it.

As for SDL_INIT_EVERYTHING: I personally wouldn’t mind getting rid of
it, I don’t use it since initializing subsystems that aren’t needed is
asking for trouble (if they fail to initialize then the entire process
will fail, even if the subsystems that are needed can initialize just
fine). I just didn’t suggest it because I don’t know how much trouble
it could cause to existent code, but even then the change is so simple
it may not matter much (and doesn’t even break binary compatibility
for programs that are already built).

2013/3/4, Ryan C. Gordon :>

Actually, that’s a good point: should we nuke SDL_INIT_EVERYTHING from
SDL 2.0?

…while I’m thinking about it, should we roll SDL_INIT_HAPTIC and
SDL_INIT_GAMECONTROLLER into SDL_INIT_JOYSTICK?

–ryan.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Jared_Maddox · March 5, 2013, 5:04am

Message-ID: <5134131E.6060101 at icculus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Yeah, that seems better. I realized later that SDL_INIT_TOUCH would
result in programs using SDL_INIT_EVERYTHING to not get emulated touch
input, but I was away by then (honestly using SDL_INIT_EVERYTHING
isn’t a good idea in the first place, but eh)

Actually, that’s a good point: should we nuke SDL_INIT_EVERYTHING from
SDL 2.0?

I mean, if we add a new subsystem, and someone has written…
if (SDL_Init(SDL_INIT_EVERYTHING) == -1)
    exit(1);
…then their working program might break when they don’t have some
exotic new functionality on their platform.

We could have a function that just returns the newest value for
SDL_INIT_EVERYTHING, but then we’d have to load SDL before SDL_Init()
even gets called. Unless you want to separate the loading stage and
the initialization stage, *_EVERYTHING should be either removed… or
changed to a discrete bit flag like all of the other init flags.

Probably it should just be removed.> Date: Sun, 03 Mar 2013 22:21:02 -0500

From: “Ryan C. Gordon”
To: SDL Development List
Subject: Re: [SDL] SDL 2.0 API stabilization
On 3/3/13 12:09 AM, Sik the hedgehog wrote:

Date: Sun, 03 Mar 2013 22:23:04 -0500
From: “Ryan C. Gordon”
To: SDL Development List
Subject: Re: [SDL] SDL 2.0 API stabilization
Message-ID: <51341398.2010406 at icculus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

…while I’m thinking about it, should we roll SDL_INIT_HAPTIC and
SDL_INIT_GAMECONTROLLER into SDL_INIT_JOYSTICK?

Don’t some mice have haptic capabilities (I half-recall magazine ads)?
Other than that, it makes sense to me.

Sik_the_hedgehog · March 5, 2013, 7:45am

I think SDL’s haptic support is limited to controllers only anyway
(correct me if I’m wrong).

2013/3/5, Jared Maddox :>> Date: Sun, 03 Mar 2013 22:21:02 -0500

From: “Ryan C. Gordon”
To: SDL Development List
Subject: Re: [SDL] SDL 2.0 API stabilization
Message-ID: <5134131E.6060101 at icculus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 3/3/13 12:09 AM, Sik the hedgehog wrote:

Yeah, that seems better. I realized later that SDL_INIT_TOUCH would
result in programs using SDL_INIT_EVERYTHING to not get emulated touch
input, but I was away by then (honestly using SDL_INIT_EVERYTHING
isn’t a good idea in the first place, but eh)

Actually, that’s a good point: should we nuke SDL_INIT_EVERYTHING from
SDL 2.0?

I mean, if we add a new subsystem, and someone has written…
if (SDL_Init(SDL_INIT_EVERYTHING) == -1)
    exit(1);
…then their working program might break when they don’t have some
exotic new functionality on their platform.
We could have a function that just returns the newest value for
SDL_INIT_EVERYTHING, but then we’d have to load SDL before SDL_Init()
even gets called. Unless you want to separate the loading stage and
the initialization stage, *_EVERYTHING should be either removed… or
changed to a discrete bit flag like all of the other init flags.

Probably it should just be removed.

Date: Sun, 03 Mar 2013 22:23:04 -0500
From: “Ryan C. Gordon”
To: SDL Development List
Subject: Re: [SDL] SDL 2.0 API stabilization
Message-ID: <51341398.2010406 at icculus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

…while I’m thinking about it, should we roll SDL_INIT_HAPTIC and
SDL_INIT_GAMECONTROLLER into SDL_INIT_JOYSTICK?

Don’t some mice have haptic capabilities (I half-recall magazine ads)?
Other than that, it makes sense to me.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

icculus · March 5, 2013, 4:13pm

Nope, he’s right, there’s an API for mice, too.

–ryan.On 3/5/13 2:45 AM, Sik the hedgehog wrote:

I think SDL’s haptic support is limited to controllers only anyway
(correct me if I’m wrong).

slouken · March 5, 2013, 6:17pm

I’m fine with removing SDL_INIT_EVERYTHING.On Mon, Mar 4, 2013 at 9:04 PM, Jared Maddox wrote:

Date: Sun, 03 Mar 2013 22:21:02 -0500
From: “Ryan C. Gordon”
To: SDL Development List
Subject: Re: [SDL] SDL 2.0 API stabilization
Message-ID: <5134131E.6060101 at icculus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 3/3/13 12:09 AM, Sik the hedgehog wrote:

Yeah, that seems better. I realized later that SDL_INIT_TOUCH would
result in programs using SDL_INIT_EVERYTHING to not get emulated touch
input, but I was away by then (honestly using SDL_INIT_EVERYTHING
isn’t a good idea in the first place, but eh)

Actually, that’s a good point: should we nuke SDL_INIT_EVERYTHING from
SDL 2.0?

I mean, if we add a new subsystem, and someone has written…
if (SDL_Init(SDL_INIT_EVERYTHING) == -1)
    exit(1);
…then their working program might break when they don’t have some
exotic new functionality on their platform.
We could have a function that just returns the newest value for
SDL_INIT_EVERYTHING, but then we’d have to load SDL before SDL_Init()
even gets called. Unless you want to separate the loading stage and
the initialization stage, *_EVERYTHING should be either removed… or
changed to a discrete bit flag like all of the other init flags.

Probably it should just be removed.

Date: Sun, 03 Mar 2013 22:23:04 -0500
From: “Ryan C. Gordon”
To: SDL Development List
Subject: Re: [SDL] SDL 2.0 API stabilization
Message-ID: <51341398.2010406 at icculus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

…while I’m thinking about it, should we roll SDL_INIT_HAPTIC and
SDL_INIT_GAMECONTROLLER into SDL_INIT_JOYSTICK?

Don’t some mice have haptic capabilities (I half-recall magazine ads)?
Other than that, it makes sense to me.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Alfred_Reynolds · March 5, 2013, 7:10pm

I find SDL_INIT_EVERYTHING useful, I have a base engine function that turns SDL on and off at the correct point in engine execution, and then all the leaf code is free to use SDL as it sees fit. Having each user of SDL functionality have to initialize (and de-init) the subsystem they want would be much more error prone, the small extra initial startup cost is well worth the reliability.
Keeping the flag does mean we can’t do destructive or intrusive operations on init (for example, start recording a video feed from an attached camera), but I would argue that init should never have those behaviors.

AlfredFrom: sdl-bounces@lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On Behalf Of Sam Lantinga
Sent: Tuesday, March 05, 2013 10:17 AM
To: SDL Development List
Subject: Re: [SDL] SDL 2.0 API stabilization

I’m fine with removing SDL_INIT_EVERYTHING.
On Mon, Mar 4, 2013 at 9:04 PM, Jared Maddox <absinthdraco at gmail.com<mailto:absinthdraco at gmail.com>> wrote:

Date: Sun, 03 Mar 2013 22:21:02 -0500
From: “Ryan C. Gordon” <icculus at icculus.org<mailto:icculus at icculus.org>>
To: SDL Development List <sdl at lists.libsdl.org<mailto:sdl at lists.libsdl.org>>
Subject: Re: [SDL] SDL 2.0 API stabilization
Message-ID: <5134131E.6060101 at icculus.org<mailto:5134131E.6060101 at icculus.org>>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 3/3/13 12:09 AM, Sik the hedgehog wrote:

Yeah, that seems better. I realized later that SDL_INIT_TOUCH would
result in programs using SDL_INIT_EVERYTHING to not get emulated touch
input, but I was away by then (honestly using SDL_INIT_EVERYTHING
isn’t a good idea in the first place, but eh)

Actually, that’s a good point: should we nuke SDL_INIT_EVERYTHING from
SDL 2.0?

I mean, if we add a new subsystem, and someone has written…
if (SDL_Init(SDL_INIT_EVERYTHING) == -1)
    exit(1);
…then their working program might break when they don’t have some
exotic new functionality on their platform.

We could have a function that just returns the newest value for
SDL_INIT_EVERYTHING, but then we’d have to load SDL before SDL_Init()
even gets called. Unless you want to separate the loading stage and
the initialization stage, *_EVERYTHING should be either removed… or
changed to a discrete bit flag like all of the other init flags.

Probably it should just be removed.

Date: Sun, 03 Mar 2013 22:23:04 -0500
From: “Ryan C. Gordon” <icculus at icculus.org<mailto:icculus at icculus.org>>
To: SDL Development List <sdl at lists.libsdl.org<mailto:sdl at lists.libsdl.org>>
Subject: Re: [SDL] SDL 2.0 API stabilization
Message-ID: <51341398.2010406 at icculus.org<mailto:51341398.2010406 at icculus.org>>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

…while I’m thinking about it, should we roll SDL_INIT_HAPTIC and
SDL_INIT_GAMECONTROLLER into SDL_INIT_JOYSTICK?

Don’t some mice have haptic capabilities (I half-recall magazine ads)?
Other than that, it makes sense to me.

SDL mailing list
SDL at lists.libsdl.org<mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Sik_the_hedgehog · March 5, 2013, 7:20pm

You can still pass all flags at the same time if you want, no need to
use SDL_InitSubsystem for each.

There’s another problem though, SDL will attempt to initialize every
subsystem passed, and if any fails to initialize, the entire process
will fail, even if other subsystems work just fine (because it assumes
you need all of them). This is why SDL_INIT_EVERYTHING is dangerous.

The above gets even more troublesome in the case Ryan mentioned
originally, if a new subsystem is added (and I have the feeling that’s
bound to happen with so many new I/O things coming out lately) then
SDL_INIT_EVERYTHING will result in failure on any system not
supporting all of the subsystems. Also it will cause issues if a new
platform is ever added, because most likely it won’t support all of
the subsystems at the same time (and depending on what peripherals it
supports, it may never do it).

2013/3/5, Alfred Reynolds :> I find SDL_INIT_EVERYTHING useful, I have a base engine function that turns

SDL on and off at the correct point in engine execution, and then all the
leaf code is free to use SDL as it sees fit. Having each user of SDL
functionality have to initialize (and de-init) the subsystem they want would
be much more error prone, the small extra initial startup cost is well worth
the reliability.
Keeping the flag does mean we can’t do destructive or intrusive operations
on init (for example, start recording a video feed from an attached camera),
but I would argue that init should never have those behaviors.

Alfred

From: sdl-bounces at lists.libsdl.org [mailto:sdl-bounces at lists.libsdl.org] On
Behalf Of Sam Lantinga
Sent: Tuesday, March 05, 2013 10:17 AM
To: SDL Development List
Subject: Re: [SDL] SDL 2.0 API stabilization

I’m fine with removing SDL_INIT_EVERYTHING.
On Mon, Mar 4, 2013 at 9:04 PM, Jared Maddox <absinthdraco at gmail.com<mailto:absinthdraco at gmail.com>> wrote:
Date: Sun, 03 Mar 2013 22:21:02 -0500
From: “Ryan C. Gordon” <icculus at icculus.org<mailto:icculus at icculus.org>>
To: SDL Development List
<sdl at lists.libsdl.org<mailto:sdl at lists.libsdl.org>>
Subject: Re: [SDL] SDL 2.0 API stabilization
Message-ID:
<5134131E.6060101 at icculus.org<mailto:5134131E.6060101 at icculus.org>>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 3/3/13 12:09 AM, Sik the hedgehog wrote:

Yeah, that seems better. I realized later that SDL_INIT_TOUCH would
result in programs using SDL_INIT_EVERYTHING to not get emulated touch
input, but I was away by then (honestly using SDL_INIT_EVERYTHING
isn’t a good idea in the first place, but eh)

Actually, that’s a good point: should we nuke SDL_INIT_EVERYTHING from
SDL 2.0?

I mean, if we add a new subsystem, and someone has written…
if (SDL_Init(SDL_INIT_EVERYTHING) == -1)
    exit(1);
…then their working program might break when they don’t have some
exotic new functionality on their platform.
We could have a function that just returns the newest value for
SDL_INIT_EVERYTHING, but then we’d have to load SDL before SDL_Init()
even gets called. Unless you want to separate the loading stage and
the initialization stage, *_EVERYTHING should be either removed… or
changed to a discrete bit flag like all of the other init flags.

Probably it should just be removed.

Date: Sun, 03 Mar 2013 22:23:04 -0500
From: “Ryan C. Gordon” <icculus at icculus.org<mailto:icculus at icculus.org>>
To: SDL Development List
<sdl at lists.libsdl.org<mailto:sdl at lists.libsdl.org>>
Subject: Re: [SDL] SDL 2.0 API stabilization
Message-ID:
<51341398.2010406 at icculus.org<mailto:51341398.2010406 at icculus.org>>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

…while I’m thinking about it, should we roll SDL_INIT_HAPTIC and
SDL_INIT_GAMECONTROLLER into SDL_INIT_JOYSTICK?

Don’t some mice have haptic capabilities (I half-recall magazine ads)?
Other than that, it makes sense to me.

SDL mailing list
SDL at lists.libsdl.org<mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

icculus · March 5, 2013, 7:35pm

Ok, then let’s change it from 0xffff to
(TIMER|AUDIO|VIDEO|JOYSTICK|etc)…this way it stays binary compatible
with exactly what you thought was “everything” when you built your app.
If you upgrade SDL, you might get a new flag added to
SDL_INIT_EVERYTHING, but you can at least control for that.

(and yeah, no cameras in init. )

–ryan.On 03/05/2013 02:10 PM, Alfred Reynolds wrote:

I find SDL_INIT_EVERYTHING useful, I have a base engine function that
turns SDL on and off at the correct point in engine execution, and then
all the leaf code is free to use SDL as it sees fit. Having each user of
SDL functionality have to initialize (and de-init) the subsystem they
want would be much more error prone, the small extra initial startup
cost is well worth the reliability.

Chris_Eineke · March 5, 2013, 11:55pm

SDL_Init shouldn’t just return 0 on success, but a mask of sub-systems
that have been successfully initialized.

chrisOn 13-03-05 02:20 PM, Sik the hedgehog wrote:

There’s another problem though, SDL will attempt to initialize every
subsystem passed, and if any fails to initialize, the entire process
will fail, even if other subsystems work just fine (because it assumes
you need all of them). This is why SDL_INIT_EVERYTHING is dangerous.

Sik_the_hedgehog · March 6, 2013, 12:00am

Then you break compatibility with just about every program out there
(every SDL 2.0 program would need to be changed) as well as
generating a massive inconsistency against other functions of the API
which return 0 on success and another value on error.

It may make more sense to do the opposite: return a mask of subsystems
that failed to initialize. Seems counterintuitive, but it could
work. Moreover, it actually follows the whole idea behind returning 0
for success: you can pass the error motive as the non-zero value.
Except that instead of one motive it’d be a bitfield of motives, but
same logic applies.

It’d still probably be wiser to have SDL_INIT_EVERYTHING only include
the bits for the currently existing subsystems and nothing else. Then
we could make it return an error if any non-used flags are passed. Not
sure how useful would that be, though.

2013/3/5, Chris Eineke :> On 13-03-05 02:20 PM, Sik the hedgehog wrote:

There’s another problem though, SDL will attempt to initialize every
subsystem passed, and if any fails to initialize, the entire process
will fail, even if other subsystems work just fine (because it assumes
you need all of them). This is why SDL_INIT_EVERYTHING is dangerous.
SDL_Init shouldn’t just return 0 on success, but a mask of sub-systems
that have been successfully initialized.

chris

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Jonathan_Greig · March 6, 2013, 2:34am

I like Sik’s suggestion on returning the failed subsystems. If there is an
issue with doing it that way, why not add a default parameter passed by
reference so that when a subsystem fails or passes, we can check that data?

Swyped from my droid.

Then you break compatibility with just about every program out there
(every SDL 2.0 program would need to be changed) as well as
generating a massive inconsistency against other functions of the API
which return 0 on success and another value on error.

It may make more sense to do the opposite: return a mask of subsystems
that failed to initialize. Seems counterintuitive, but it could
work. Moreover, it actually follows the whole idea behind returning 0
for success: you can pass the error motive as the non-zero value.
Except that instead of one motive it’d be a bitfield of motives, but
same logic applies.

It’d still probably be wiser to have SDL_INIT_EVERYTHING only include
the bits for the currently existing subsystems and nothing else. Then
we could make it return an error if any non-used flags are passed. Not
sure how useful would that be, though.

2013/3/5, Chris Eineke :On Mar 5, 2013 6:00 PM, “Sik the hedgehog” <sik.the.hedgehog at gmail.com> wrote:

On 13-03-05 02:20 PM, Sik the hedgehog wrote:

There’s another problem though, SDL will attempt …

Vittorio_Giovara · March 7, 2013, 9:03am

So, for a brief moment there was a half idea of moving the sdl api from
SDL_VERB_NOUN to SDL_NOUN_VERB
so that for example SDL_TryLockMutex() would become SDL_MutexTryLock()
This idea was thought on the basis that it would make the alphabetical
listing more logical and would simplify grouping similar APIs.

Is this idea still lingering around (and it’s just a matter of volunteers
submitting patches) or has it been discarded completely?
Cheers,
VittorioOn Mon, Feb 18, 2013 at 8:19 AM, Sam Lantinga wrote:

We’re on the road to release for SDL 2.0.

To that end, most of the existing APIs are stable, and we’ll only change
them if it’s critical.
There are a few things which are still being considered, such as the iOS
event handling, and touch/mouse event semantics, but by and large the API
is set for release.

Please report bugs which are affecting you in the current snapshot:
http://www.libsdl.org/tmp/SDL-2.0.zip

If anyone wants to fix anything currently in bugzilla, they are more than
welcome:
http://bugzilla.libsdl.org

Cheers!
–Sam

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Sik_the_hedgehog · March 7, 2013, 10:15am

The problem would be that then you’d have to rename about every
function in order to achieve that, and I don’t think many people would
be happy with that (and besides, even though the SDL2 API still
isn’t 100% fixed, I don’t think that doing a near complete rewrite of
existent SDL2 programs is going to be a good idea).

I’m not sure many people look up for a function in an alphabetical
list, though. Functions are already separated by category (both in the
wiki and in doxygen), in practice that seems to be way more useful
(and in fact it’s pretty much the only way I look up for SDL
functions). If you already know the name beforehand an alphabetical
list is better, but at that point you don’t care about whether it’s
organized by categories or not.

2013/3/7, Vittorio Giovara <vittorio.giovara at gmail.com>:> So, for a brief moment there was a half idea of moving the sdl api from

SDL_VERB_NOUN to SDL_NOUN_VERB
so that for example SDL_TryLockMutex() would become SDL_MutexTryLock()
This idea was thought on the basis that it would make the alphabetical
listing more logical and would simplify grouping similar APIs.

Is this idea still lingering around (and it’s just a matter of volunteers
submitting patches) or has it been discarded completely?
Cheers,
Vittorio

On Mon, Feb 18, 2013 at 8:19 AM, Sam Lantinga wrote:

We’re on the road to release for SDL 2.0.

To that end, most of the existing APIs are stable, and we’ll only change
them if it’s critical.
There are a few things which are still being considered, such as the iOS
event handling, and touch/mouse event semantics, but by and large the API
is set for release.

Please report bugs which are affecting you in the current snapshot:
http://www.libsdl.org/tmp/SDL-2.0.zip

If anyone wants to fix anything currently in bugzilla, they are more than
welcome:
http://bugzilla.libsdl.org

Cheers!
–Sam

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Alexey_Petruchik · March 7, 2013, 10:26am

Another controversial proposal Maybe it’s time to remove SDL integer
types (Uint8, …) in favor of <stdint.h> types (uint8_t, int8_t, …)? SDL
integer types are just typedefs to stdint.h types so why we need them at
all? SDL integer types removal will encourage programmers to use <stdint.h>
types in their programs instead of spawning
yet-another-alias-for-thing-that-already-has-a-name.On Thu, Mar 7, 2013 at 1:15 PM, Sik the hedgehog <sik.the.hedgehog at gmail.com wrote:

The problem would be that then you’d have to rename about every
function in order to achieve that, and I don’t think many people would
be happy with that (and besides, even though the SDL2 API still
isn’t 100% fixed, I don’t think that doing a near complete rewrite of
existent SDL2 programs is going to be a good idea).

I’m not sure many people look up for a function in an alphabetical
list, though. Functions are already separated by category (both in the
wiki and in doxygen), in practice that seems to be way more useful
(and in fact it’s pretty much the only way I look up for SDL
functions). If you already know the name beforehand an alphabetical
list is better, but at that point you don’t care about whether it’s
organized by categories or not.

2013/3/7, Vittorio Giovara <vittorio.giovara at gmail.com>:

So, for a brief moment there was a half idea of moving the sdl api from
SDL_VERB_NOUN to SDL_NOUN_VERB
so that for example SDL_TryLockMutex() would become SDL_MutexTryLock()
This idea was thought on the basis that it would make the alphabetical
listing more logical and would simplify grouping similar APIs.

Is this idea still lingering around (and it’s just a matter of volunteers
submitting patches) or has it been discarded completely?
Cheers,
Vittorio

On Mon, Feb 18, 2013 at 8:19 AM, Sam Lantinga wrote:

We’re on the road to release for SDL 2.0.

To that end, most of the existing APIs are stable, and we’ll only change
them if it’s critical.
There are a few things which are still being considered, such as the iOS
event handling, and touch/mouse event semantics, but by and large the
API
is set for release.

Please report bugs which are affecting you in the current snapshot:
http://www.libsdl.org/tmp/SDL-2.0.zip

If anyone wants to fix anything currently in bugzilla, they are more
than
welcome:
http://bugzilla.libsdl.org

Cheers!
–Sam

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org