SDL 2.0 API stabilization

[Sik_the_hedgehog]

In my experience programmers have a tendency to ignore stdint.h
whenever possible

Now seriously, I completely ignored SDL types in favor of the stdint.h
ones so I wouldn’t care about such a change. I don’t know how many
projects rely on them, though, so no idea how much of an impact this
change would cause.

I suppose that in the worst case we could always tell the programmers
to just do this:

typedef Int8 int8_t;
typedef Int16 int16_t;
typedef Int32 int32_t;
typedef Int64 int64_t;
typedef Uint8 uint8_t;
typedef Uint16 uint16_t;
typedef Uint32 uint32_t;
typedef Uint64 uint64_t;

PS: if I recall correctly MSVS didn’t come with stdint.h at all until
relatively recent versions, so I imagine that SDL not relying on
stdint.h may have been influenced by that.

2013/3/7, Alexey Petruchik :> 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 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

[Alexey_Petruchik]

In my experience programmers have a tendency to ignore stdint.h whenever possible
It’s obviously a bad practice, isn’t it?

how much of an impact this change would cause.
SDL 2.0 is already not backward compatible with SDL 1.2

if I recall correctly MSVS didn’t come with stdint.h at all until relatively recent versions
Yes, they had added stdint.h in 2010. Yes there is no stdint.h on some
platforms and old compilers.
But SDL already has code to define stdint.h types on platforms where
it’s missing (old MSVS, nintendods, …)On Thu, Mar 7, 2013 at 2:26 PM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:
In my experience programmers have a tendency to ignore stdint.h
whenever possible

Now seriously, I completely ignored SDL types in favor of the stdint.h
ones so I wouldn’t care about such a change. I don’t know how many
projects rely on them, though, so no idea how much of an impact this
change would cause.

I suppose that in the worst case we could always tell the programmers
to just do this:

typedef Int8 int8_t;
typedef Int16 int16_t;
typedef Int32 int32_t;
typedef Int64 int64_t;
typedef Uint8 uint8_t;
typedef Uint16 uint16_t;
typedef Uint32 uint32_t;
typedef Uint64 uint64_t;

PS: if I recall correctly MSVS didn’t come with stdint.h at all until
relatively recent versions, so I imagine that SDL not relying on
stdint.h may have been influenced by that.

2013/3/7, Alexey Petruchik :

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

---

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

[Sik_the_hedgehog]

My concern isn’t with programs using SDL 1.2, but with programs that
already use SDL2. It has been quite a long time so I guess there’s a
good chunk out there. Although I wonder how many programmers even
bothered to use size-defined types for starters.

Again, I suppose that in the worst case we could just tell developers
to use those typedefs I mentioned earlier and save them the headache
of rewriting code.

2013/3/7, Alexey Petruchik :>> In my experience programmers have a tendency to ignore stdint.h whenever

possible
It’s obviously a bad practice, isn’t it?

how much of an impact this change would cause.
SDL 2.0 is already not backward compatible with SDL 1.2

if I recall correctly MSVS didn’t come with stdint.h at all until
relatively recent versions
Yes, they had added stdint.h in 2010. Yes there is no stdint.h on some
platforms and old compilers.
But SDL already has code to define stdint.h types on platforms where
it’s missing (old MSVS, nintendods, …)

On Thu, Mar 7, 2013 at 2:26 PM, Sik the hedgehog <@Sik_the_hedgehog> wrote:

In my experience programmers have a tendency to ignore stdint.h
whenever possible

Now seriously, I completely ignored SDL types in favor of the stdint.h
ones so I wouldn’t care about such a change. I don’t know how many
projects rely on them, though, so no idea how much of an impact this
change would cause.

I suppose that in the worst case we could always tell the programmers
to just do this:

typedef Int8 int8_t;
typedef Int16 int16_t;
typedef Int32 int32_t;
typedef Int64 int64_t;
typedef Uint8 uint8_t;
typedef Uint16 uint16_t;
typedef Uint32 uint32_t;
typedef Uint64 uint64_t;

PS: if I recall correctly MSVS didn’t come with stdint.h at all until
relatively recent versions, so I imagine that SDL not relying on
stdint.h may have been influenced by that.

2013/3/7, Alexey Petruchik :

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 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

---

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

[Tim_Angus]

You could provide a big pile of #define SDL_VerbNoun SDL_NounVerb…On 07/03/13 10:15, Sik the hedgehog 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).

[David_Gow]

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).

You could provide a big pile of #define SDL_VerbNoun SDL_NounVerb…

That’d still really break binary compatibility.

– DavidOn 07/03/13 20:37, Tim Angus wrote:

On 07/03/13 10:15, Sik the hedgehog wrote:

---

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

[JonnyD]

If NounVerb and size types are going to change, they should change now.
Everyone using SDL2 (myself included) is aware that things will change out
from under them until the API is frozen. That’s just a fact of software
development sometimes. There’s no reason to do a lesser job with SDL2 just
because it’d be an inconvenience to the people testing it out. I use the
size types heavily, but if they change I’m cool with updating my code.
Both changes are of the “find & replace” variety, which should be no
problem compared to semantic changes.

I thought that the size types might also make the API more portable to
other languages that do not have the identical stdint types?

Jonny DOn Thu, Mar 7, 2013 at 7:37 AM, Tim Angus wrote:

On 07/03/13 10:15, Sik the hedgehog 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).

You could provide a big pile of #define SDL_VerbNoun SDL_NounVerb…

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

[Sik_the_hedgehog]

If you think that renaming about every function is good enough then we
may as well start dissecting other things which are giving us trouble,
like e.g. mouse and cursor being handled as the same thing by SDL
(which ended up leading us to the whole touch emulation shenanigans -
if they were separate then touch would affect the cursor and not the
mouse) or some things not being thread safe (can’t come up with an
exact list at the moment but if I recall correctly some stuff still
relies on global states when it could be avoided).

I understand the API isn’t stable yet but I doubt that means huge
changes are going to be allowed. Especially not now that Valve is
using it, they probably don’t want having to rewrite lots of code by
this point.

2013/3/7, Jonathan Dearborn :> If NounVerb and size types are going to change, they should change now.

Everyone using SDL2 (myself included) is aware that things will change out
from under them until the API is frozen. That’s just a fact of software
development sometimes. There’s no reason to do a lesser job with SDL2 just
because it’d be an inconvenience to the people testing it out. I use the
size types heavily, but if they change I’m cool with updating my code.
Both changes are of the “find & replace” variety, which should be no
problem compared to semantic changes.

I thought that the size types might also make the API more portable to
other languages that do not have the identical stdint types?

Jonny D

On Thu, Mar 7, 2013 at 7:37 AM, Tim Angus wrote:

On 07/03/13 10:15, Sik the hedgehog 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).

You could provide a big pile of #define SDL_VerbNoun SDL_NounVerb…

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

[JonnyD]

Well, Sam has already indicated (see first post in this thread) that
mouse/touch semantics are in need of work. Is it more than just the events
that are an issue for you?

Affecting Valve is a moot point. For their SDL2 code, they have engineers
that are at least as capable as any of us. We would need to break a lot of
stuff for them to feel it.

Things like thread safety do not affect API stabilization. As I said,
these two changes in particular are just “find & replace” fixes, not
rewrites. They feel like big changes, but they do not change the way your
write or think about the code.

SDL is supposed to be a community-led project, which means putting the
community’s thoughts first. If enough people think these are good ideas,
then they will happen regardless of the implications to users of an
unstable API.

Jonny DOn Thu, Mar 7, 2013 at 9:42 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com wrote:

If you think that renaming about every function is good enough then we
may as well start dissecting other things which are giving us trouble,
like e.g. mouse and cursor being handled as the same thing by SDL
(which ended up leading us to the whole touch emulation shenanigans -
if they were separate then touch would affect the cursor and not the
mouse) or some things not being thread safe (can’t come up with an
exact list at the moment but if I recall correctly some stuff still
relies on global states when it could be avoided).

I understand the API isn’t stable yet but I doubt that means huge
changes are going to be allowed. Especially not now that Valve is
using it, they probably don’t want having to rewrite lots of code by
this point.

2013/3/7, Jonathan Dearborn <@Jonathan_Dearborn>:

If NounVerb and size types are going to change, they should change now.
Everyone using SDL2 (myself included) is aware that things will change
out
from under them until the API is frozen. That’s just a fact of software
development sometimes. There’s no reason to do a lesser job with SDL2
just
because it’d be an inconvenience to the people testing it out. I use the
size types heavily, but if they change I’m cool with updating my code.
Both changes are of the “find & replace” variety, which should be no
problem compared to semantic changes.

I thought that the size types might also make the API more portable to
other languages that do not have the identical stdint types?

Jonny D

On Thu, Mar 7, 2013 at 7:37 AM, Tim Angus wrote:

On 07/03/13 10:15, Sik the hedgehog 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).

You could provide a big pile of #define SDL_VerbNoun SDL_NounVerb…

_____________**
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

[Sik_the_hedgehog]

The problem with touch is the whole emulation of mouse events. This is
considered an issue because in SDL the mouse is the same thing as the
cursor, despite the fact this isn’t the case for the operating system.
The cursor is what interacts with the user interface, the mouse is…
the mouse. For the operating system, the mouse affects the cursor and
so does touch. Even other devices may affect the cursor. This is why
the cursor is a separate thing, even if it was effectively equivalent
to the mouse for so long.

Note that it isn’t just events that are an issue, is the entire thing.
Touch emulating the mouse causes the mouse state to be changed. If the
cursor was a separate thing, touch would affect the cursor state, but
not the mouse. I suppose you could make a case that nobody would want
to use mouse and touch at the same time, but it still can result in
undesirable side-effects (e.g. what if somebody uses touch for the UI,
then goes with the mouse for looking around in a game? the position of
the mouse would be jumping around all the time)

For the record, at some point mouse and cursor were supposed to be
separated, if the wiki is anything to go by. No idea why they went
back with that.

And if I recall correctly, before it was mentioned that making libtool
output the same filename as cmake would break what Valve already has
out. I would imagine that changing the API like that would break it
just as badly.

2013/3/7, Jonathan Dearborn :> Well, Sam has already indicated (see first post in this thread) that

mouse/touch semantics are in need of work. Is it more than just the events
that are an issue for you?

Affecting Valve is a moot point. For their SDL2 code, they have engineers
that are at least as capable as any of us. We would need to break a lot of
stuff for them to feel it.

Things like thread safety do not affect API stabilization. As I said,
these two changes in particular are just “find & replace” fixes, not
rewrites. They feel like big changes, but they do not change the way your
write or think about the code.

SDL is supposed to be a community-led project, which means putting the
community’s thoughts first. If enough people think these are good ideas,
then they will happen regardless of the implications to users of an
unstable API.

Jonny D

On Thu, Mar 7, 2013 at 9:42 AM, Sik the hedgehog <@Sik_the_hedgehog wrote:

If you think that renaming about every function is good enough then we
may as well start dissecting other things which are giving us trouble,
like e.g. mouse and cursor being handled as the same thing by SDL
(which ended up leading us to the whole touch emulation shenanigans -
if they were separate then touch would affect the cursor and not the
mouse) or some things not being thread safe (can’t come up with an
exact list at the moment but if I recall correctly some stuff still
relies on global states when it could be avoided).

I understand the API isn’t stable yet but I doubt that means huge
changes are going to be allowed. Especially not now that Valve is
using it, they probably don’t want having to rewrite lots of code by
this point.

2013/3/7, Jonathan Dearborn :

If NounVerb and size types are going to change, they should change now.
Everyone using SDL2 (myself included) is aware that things will change
out
from under them until the API is frozen. That’s just a fact of
software
development sometimes. There’s no reason to do a lesser job with SDL2
just
because it’d be an inconvenience to the people testing it out. I use
the
size types heavily, but if they change I’m cool with updating my code.
Both changes are of the “find & replace” variety, which should be no
problem compared to semantic changes.

I thought that the size types might also make the API more portable to
other languages that do not have the identical stdint types?

Jonny D

On Thu, Mar 7, 2013 at 7:37 AM, Tim Angus wrote:

On 07/03/13 10:15, Sik the hedgehog 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).

You could provide a big pile of #define SDL_VerbNoun SDL_NounVerb…

_____________**
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

[John6]

Wait, is the API already declared frozen?On 03/07/2013 10:54 AM, Sik the hedgehog wrote:

The problem with touch is the whole emulation of mouse events. This is
considered an issue because in SDL the mouse is the same thing as the
cursor, despite the fact this isn’t the case for the operating system.
The cursor is what interacts with the user interface, the mouse is…
the mouse. For the operating system, the mouse affects the cursor and
so does touch. Even other devices may affect the cursor. This is why
the cursor is a separate thing, even if it was effectively equivalent
to the mouse for so long.

Note that it isn’t just events that are an issue, is the entire thing.
Touch emulating the mouse causes the mouse state to be changed. If the
cursor was a separate thing, touch would affect the cursor state, but
not the mouse. I suppose you could make a case that nobody would want
to use mouse and touch at the same time, but it still can result in
undesirable side-effects (e.g. what if somebody uses touch for the UI,
then goes with the mouse for looking around in a game? the position of
the mouse would be jumping around all the time)

For the record, at some point mouse and cursor were supposed to be
separated, if the wiki is anything to go by. No idea why they went
back with that.

And if I recall correctly, before it was mentioned that making libtool
output the same filename as cmake would break what Valve already has
out. I would imagine that changing the API like that would break it
just as badly.

2013/3/7, Jonathan Dearborn :

Well, Sam has already indicated (see first post in this thread) that
mouse/touch semantics are in need of work. Is it more than just the events
that are an issue for you?

Affecting Valve is a moot point. For their SDL2 code, they have engineers
that are at least as capable as any of us. We would need to break a lot of
stuff for them to feel it.

Things like thread safety do not affect API stabilization. As I said,
these two changes in particular are just “find & replace” fixes, not
rewrites. They feel like big changes, but they do not change the way your
write or think about the code.

SDL is supposed to be a community-led project, which means putting the
community’s thoughts first. If enough people think these are good ideas,
then they will happen regardless of the implications to users of an
unstable API.

Jonny D

On Thu, Mar 7, 2013 at 9:42 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com wrote:

If you think that renaming about every function is good enough then we
may as well start dissecting other things which are giving us trouble,
like e.g. mouse and cursor being handled as the same thing by SDL
(which ended up leading us to the whole touch emulation shenanigans -
if they were separate then touch would affect the cursor and not the
mouse) or some things not being thread safe (can’t come up with an
exact list at the moment but if I recall correctly some stuff still
relies on global states when it could be avoided).

I understand the API isn’t stable yet but I doubt that means huge
changes are going to be allowed. Especially not now that Valve is
using it, they probably don’t want having to rewrite lots of code by
this point.

2013/3/7, Jonathan Dearborn :

If NounVerb and size types are going to change, they should change now.
Everyone using SDL2 (myself included) is aware that things will change
out
from under them until the API is frozen. That’s just a fact of
software
development sometimes. There’s no reason to do a lesser job with SDL2
just
because it’d be an inconvenience to the people testing it out. I use
the
size types heavily, but if they change I’m cool with updating my code.
Both changes are of the “find & replace” variety, which should be no
problem compared to semantic changes.

I thought that the size types might also make the API more portable to
other languages that do not have the identical stdint types?

Jonny D

On Thu, Mar 7, 2013 at 7:37 AM, Tim Angus wrote:

On 07/03/13 10:15, Sik the hedgehog 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).

You could provide a big pile of #define SDL_VerbNoun SDL_NounVerb…

_____________**
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

[Sik_the_hedgehog]

No, the problem is that one of the changes proposed involves renaming
a large chunk of the functions (the vast majority, I think) and we
started arguing for that reason. (there’s also the getting rid of
types one but that one can be fixed by just adding a few typedefs
without much trouble)

2013/3/7, John :> Wait, is the API already declared frozen?

On 03/07/2013 10:54 AM, Sik the hedgehog wrote:

The problem with touch is the whole emulation of mouse events. This is
considered an issue because in SDL the mouse is the same thing as the
cursor, despite the fact this isn’t the case for the operating system.
The cursor is what interacts with the user interface, the mouse is…
the mouse. For the operating system, the mouse affects the cursor and
so does touch. Even other devices may affect the cursor. This is why
the cursor is a separate thing, even if it was effectively equivalent
to the mouse for so long.

Note that it isn’t just events that are an issue, is the entire thing.
Touch emulating the mouse causes the mouse state to be changed. If the
cursor was a separate thing, touch would affect the cursor state, but
not the mouse. I suppose you could make a case that nobody would want
to use mouse and touch at the same time, but it still can result in
undesirable side-effects (e.g. what if somebody uses touch for the UI,
then goes with the mouse for looking around in a game? the position of
the mouse would be jumping around all the time)

For the record, at some point mouse and cursor were supposed to be
separated, if the wiki is anything to go by. No idea why they went
back with that.

And if I recall correctly, before it was mentioned that making libtool
output the same filename as cmake would break what Valve already has
out. I would imagine that changing the API like that would break it
just as badly.

2013/3/7, Jonathan Dearborn :

Well, Sam has already indicated (see first post in this thread) that
mouse/touch semantics are in need of work. Is it more than just the
events
that are an issue for you?

Affecting Valve is a moot point. For their SDL2 code, they have
engineers
that are at least as capable as any of us. We would need to break a lot
of
stuff for them to feel it.

Things like thread safety do not affect API stabilization. As I said,
these two changes in particular are just “find & replace” fixes, not
rewrites. They feel like big changes, but they do not change the way
your
write or think about the code.

SDL is supposed to be a community-led project, which means putting the
community’s thoughts first. If enough people think these are good
ideas,
then they will happen regardless of the implications to users of an
unstable API.

Jonny D

On Thu, Mar 7, 2013 at 9:42 AM, Sik the hedgehog <@Sik_the_hedgehog wrote:

If you think that renaming about every function is good enough then we
may as well start dissecting other things which are giving us trouble,
like e.g. mouse and cursor being handled as the same thing by SDL
(which ended up leading us to the whole touch emulation shenanigans -
if they were separate then touch would affect the cursor and not the
mouse) or some things not being thread safe (can’t come up with an
exact list at the moment but if I recall correctly some stuff still
relies on global states when it could be avoided).

I understand the API isn’t stable yet but I doubt that means huge
changes are going to be allowed. Especially not now that Valve is
using it, they probably don’t want having to rewrite lots of code by
this point.

2013/3/7, Jonathan Dearborn :

If NounVerb and size types are going to change, they should change
now.
Everyone using SDL2 (myself included) is aware that things will
change
out
from under them until the API is frozen. That’s just a fact of
software
development sometimes. There’s no reason to do a lesser job with SDL2
just
because it’d be an inconvenience to the people testing it out. I use
the
size types heavily, but if they change I’m cool with updating my code.
Both changes are of the “find & replace” variety, which should be no
problem compared to semantic changes.

I thought that the size types might also make the API more portable to
other languages that do not have the identical stdint types?

Jonny D

On Thu, Mar 7, 2013 at 7:37 AM, Tim Angus wrote:

On 07/03/13 10:15, Sik the hedgehog 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).

You could provide a big pile of #define SDL_VerbNoun SDL_NounVerb…

_____________**
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