[SDL] MacPort SDL library

Lucas franca do nascimento farias lucasfnf at gmail.com
Wed Mar 20 09:36:03 PDT 2013

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

More information about the SDL mailing list