[SDL] SDL 2.0 API stabilization

Sik the hedgehog sik.the.hedgehog at gmail.com
Thu Mar 7 08:40:39 PST 2013


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 <john at leafygreengames.com>:
> 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 <grimfang4 at gmail.com>:
>>> 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 <grimfang4 at gmail.com>:
>>>>> 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 <tim at ngus.net> 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
>



More information about the SDL mailing list