Mouse emulation of touch events

John5 · November 29, 2012, 11:31pm

Hi,

The patch in the SDL trunk (listed below) breaks apps that correctly handle
mouse and touch events. Apps will receive mouse events AND touch events. Also,
the precision of the mouse events will be incredibly lossy due to integer
truncation when compared with the touch events, which have double precision.

Recommend removing this patch altogether.

The patch in question is http://hg.libsdl.org/SDL/raw-rev/17ef8a7cab55
in file “src/video/android/SDL_androidtouch.c”

-John

slouken · December 1, 2012, 10:17pm

This is a required feature for games that use gesture support as well as
mouse interaction. If you prefer to use only touch events, can you ignore
the mouse events?On Thu, Nov 29, 2012 at 3:31 PM, John wrote:

Hi,

The patch in the SDL trunk (listed below) breaks apps that correctly
handle mouse and touch events. Apps will receive mouse events AND touch
events. Also, the precision of the mouse events will be incredibly lossy
due to integer truncation when compared with the touch events, which have
double precision.

Recommend removing this patch altogether.

The patch in question is http://hg.libsdl.org/SDL/raw-**rev/17ef8a7cab55 http://hg.libsdl.org/SDL/raw-rev/17ef8a7cab55
in file “src/video/android/SDL_**androidtouch.c”

-John

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

John5 · December 2, 2012, 2:02am

How will the app event handler know whether to ignore mouse events?

I think the issue is that now SDL is always in this emulation mode. It generates
fake mouse events whenever it sees touch events, then delivers BOTH events to
the app. From the perspective of an app’s event loop, sometimes SDL_MouseEvent
is really a mouse event, and sometimes it is a duplicate of a touch event or a
finger event.

I guess this is really a question of what an app event loop should look like
now. Say an app’s event handler resembles this code,

case SDL_MOUSEBUTTONDOWN: handle_mousedown(); break;
case SDL_TOUCHBUTTONDOWN: handle_touchbuttondown(); break;
case SDL_FINGERDOWN: handle_fingerdown(); break;
case SDL_MOUSEMOTION: handle_mousemotion(); break;
case SDL_FINGERMOTION: handle_fingermotion(); break;
case SDL_MOUSEWHEEL: handle_mousewheel(); break;
…etc.

How would you recommend app developers revise their event handlers to work after
the mouse emulation patch?On 12/01/2012 05:17 PM, Sam Lantinga wrote:

This is a required feature for games that use gesture support as well as mouse
interaction. If you prefer to use only touch events, can you ignore the mouse
events?

On Thu, Nov 29, 2012 at 3:31 PM, John <@John5 mailto:John5> wrote:

Hi,

The patch in the SDL trunk (listed below) breaks apps that correctly handle
mouse and touch events. Apps will receive mouse events AND touch events.
Also, the precision of the mouse events will be incredibly lossy due to
integer truncation when compared with the touch events, which have double
precision.

Recommend removing this patch altogether.

The patch in question is http://hg.libsdl.org/SDL/raw-__rev/17ef8a7cab55
<http://hg.libsdl.org/SDL/raw-rev/17ef8a7cab55>
in file "src/video/android/SDL___androidtouch.c"


-John


_________________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto: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 · December 2, 2012, 3:08am

So you want to distinguish between cursor events caused by the mouse
and cursor events caused by touch, if I’m understanding right?
(honestly it should be called cursor, not mouse)

2012/12/1 John :> How will the app event handler know whether to ignore mouse events?

I think the issue is that now SDL is always in this emulation mode. It
generates fake mouse events whenever it sees touch events, then delivers
BOTH events to the app. From the perspective of an app’s event loop,
sometimes SDL_MouseEvent is really a mouse event, and sometimes it is a
duplicate of a touch event or a finger event.

I guess this is really a question of what an app event loop should look like
now. Say an app’s event handler resembles this code,

case SDL_MOUSEBUTTONDOWN: handle_mousedown(); break;
case SDL_TOUCHBUTTONDOWN: handle_touchbuttondown(); break;
case SDL_FINGERDOWN: handle_fingerdown(); break;
case SDL_MOUSEMOTION: handle_mousemotion(); break;
case SDL_FINGERMOTION: handle_fingermotion(); break;
case SDL_MOUSEWHEEL: handle_mousewheel(); break;
…etc.

How would you recommend app developers revise their event handlers to work
after the mouse emulation patch?

On 12/01/2012 05:17 PM, Sam Lantinga wrote:
This is a required feature for games that use gesture support as well as
mouse
interaction. If you prefer to use only touch events, can you ignore the
mouse
events?

On Thu, Nov 29, 2012 at 3:31 PM, John <john at puckerupgames.com <mailto:john at puckerupgames.com>> wrote:
Hi,

The patch in the SDL trunk (listed below) breaks apps that correctly
handle
mouse and touch events. Apps will receive mouse events AND touch
events.
Also, the precision of the mouse events will be incredibly lossy due
to
integer truncation when compared with the touch events, which have
double
precision.
Recommend removing this patch altogether.

The patch in question is
http://hg.libsdl.org/SDL/raw-__rev/17ef8a7cab55
http://hg.libsdl.org/SDL/raw-rev/17ef8a7cab55
in file “src/video/android/SDL___androidtouch.c”
-John


_________________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto: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

John5 · December 2, 2012, 4:47am

Yes, sort of. It’s not important to me whether the events were truly triggered
by such-and-such device, although I can see why an app might need that. I’d like
to know how a “well behaved” app event loop should interpret the new SDL events.
Knowing that, I can revise my apps to follow suit.

Perhaps a real example would make more sense: A game displays a button graphic.
The player can “press” the on-screen button with a mouse down event. They may
also press the on-screen button with a finger event. The app handles both
events, and it handles the “up” events as well in order to alter the button
appearance. Just your typical “onmousedown/onmouseup” sort of stuff. The code
compiles nicely on all platforms that SDL supports. Now, with the mouse
emulation patch applied, on Android, when the user touches the screen, the app
recieves a flurry of mouse events AND touch events. The mousemotion is even
weirder, because the mouse emulation patch generates very sudden, fast motion
when there is no motion at all. On finger-down, SDL moves the “fake” mouse
location from it’s previously fake location to the new finger location by
generating a mouse motion event. Kinda like the old WarpMouse call.

Here’s the event sequence on Android before the patch, when the user touches the
screen then releases:

FINGERDOWN
FINGERMOTION
FINGERMOTION… dozens of these.
FINGERUP

Here’s the event sequence after the emulation patch:

MOUSEMOTION
MOUSEBUTTONDOWN
FINGERDOWN
MOUSEMOTION,FINGERMOTION,… dozens of these pairs.
MOUSEBUTTONUP
FINGERUPOn 12/01/2012 10:08 PM, Sik the hedgehog wrote:

So you want to distinguish between cursor events caused by the mouse
and cursor events caused by touch, if I’m understanding right?
(honestly it should be called cursor, not mouse)

2012/12/1 John <@John5>:
How will the app event handler know whether to ignore mouse events?

I think the issue is that now SDL is always in this emulation mode. It
generates fake mouse events whenever it sees touch events, then delivers
BOTH events to the app. From the perspective of an app’s event loop,
sometimes SDL_MouseEvent is really a mouse event, and sometimes it is a
duplicate of a touch event or a finger event.

I guess this is really a question of what an app event loop should look like
now. Say an app’s event handler resembles this code,

case SDL_MOUSEBUTTONDOWN: handle_mousedown(); break;
case SDL_TOUCHBUTTONDOWN: handle_touchbuttondown(); break;
case SDL_FINGERDOWN: handle_fingerdown(); break;
case SDL_MOUSEMOTION: handle_mousemotion(); break;
case SDL_FINGERMOTION: handle_fingermotion(); break;
case SDL_MOUSEWHEEL: handle_mousewheel(); break;
…etc.

How would you recommend app developers revise their event handlers to work
after the mouse emulation patch?

On 12/01/2012 05:17 PM, Sam Lantinga wrote:
This is a required feature for games that use gesture support as well as
mouse
interaction. If you prefer to use only touch events, can you ignore the
mouse
events?

On Thu, Nov 29, 2012 at 3:31 PM, John <@John5 mailto:John5> wrote:
 Hi,

 The patch in the SDL trunk (listed below) breaks apps that correctly
handle
mouse and touch events. Apps will receive mouse events AND touch
events.
Also, the precision of the mouse events will be incredibly lossy due
to
integer truncation when compared with the touch events, which have
double
precision.
 Recommend removing this patch altogether.

 The patch in question is
http://hg.libsdl.org/SDL/raw-__rev/17ef8a7cab55
http://hg.libsdl.org/SDL/raw-rev/17ef8a7cab55
in file “src/video/android/SDL___androidtouch.c”
 -John


 _________________________________________________
 SDL mailing list
 SDL at lists.libsdl.org <mailto: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

Sik_the_hedgehog · December 2, 2012, 6:08am

Well, I assume the idea behind the patch is so that programs that
weren’t designed for touch in the first place can act accordingly when
a touch screen is used (since again, those are really cursor events,
not mouse events - the name is a misnomer).

Dunno what you’re asking about? If you mean about handling the cursor
as-is, unless you’re handling specific gestures you should probably
use only the cursor events - though cursor events are quite barebones,
I had suggested a double click event some time ago (which could be
mapped to whatever is the touch equivalent).

I guess it depends on whether you just want a barebones generic cursor
or want to handle touch gestures specifically.

2012/12/2 John :> Yes, sort of. It’s not important to me whether the events were truly

triggered by such-and-such device, although I can see why an app might need
that. I’d like to know how a “well behaved” app event loop should interpret
the new SDL events. Knowing that, I can revise my apps to follow suit.

Perhaps a real example would make more sense: A game displays a button
graphic. The player can “press” the on-screen button with a mouse down
event. They may also press the on-screen button with a finger event. The app
handles both events, and it handles the “up” events as well in order to
alter the button appearance. Just your typical “onmousedown/onmouseup” sort
of stuff. The code compiles nicely on all platforms that SDL supports. Now,
with the mouse emulation patch applied, on Android, when the user touches
the screen, the app recieves a flurry of mouse events AND touch events. The
mousemotion is even weirder, because the mouse emulation patch generates
very sudden, fast motion when there is no motion at all. On finger-down, SDL
moves the “fake” mouse location from it’s previously fake location to the
new finger location by generating a mouse motion event. Kinda like the old
WarpMouse call.

Here’s the event sequence on Android before the patch, when the user touches
the screen then releases:

FINGERDOWN
FINGERMOTION
FINGERMOTION… dozens of these.
FINGERUP

Here’s the event sequence after the emulation patch:

MOUSEMOTION
MOUSEBUTTONDOWN
FINGERDOWN
MOUSEMOTION,FINGERMOTION,… dozens of these pairs.
MOUSEBUTTONUP
FINGERUP

On 12/01/2012 10:08 PM, Sik the hedgehog wrote:
So you want to distinguish between cursor events caused by the mouse
and cursor events caused by touch, if I’m understanding right?
(honestly it should be called cursor, not mouse)

2012/12/1 John :
How will the app event handler know whether to ignore mouse events?

I think the issue is that now SDL is always in this emulation mode. It
generates fake mouse events whenever it sees touch events, then delivers
BOTH events to the app. From the perspective of an app’s event loop,
sometimes SDL_MouseEvent is really a mouse event, and sometimes it is a
duplicate of a touch event or a finger event.

I guess this is really a question of what an app event loop should look
like
now. Say an app’s event handler resembles this code,

case SDL_MOUSEBUTTONDOWN: handle_mousedown(); break;
case SDL_TOUCHBUTTONDOWN: handle_touchbuttondown(); break;
case SDL_FINGERDOWN: handle_fingerdown(); break;
case SDL_MOUSEMOTION: handle_mousemotion(); break;
case SDL_FINGERMOTION: handle_fingermotion(); break;
case SDL_MOUSEWHEEL: handle_mousewheel(); break;
…etc.

How would you recommend app developers revise their event handlers to
work
after the mouse emulation patch?

On 12/01/2012 05:17 PM, Sam Lantinga wrote:
This is a required feature for games that use gesture support as well as
mouse
interaction. If you prefer to use only touch events, can you ignore the
mouse
events?

On Thu, Nov 29, 2012 at 3:31 PM, John <john at puckerupgames.com <mailto:john at puckerupgames.com>> wrote:
 Hi,

 The patch in the SDL trunk (listed below) breaks apps that
correctly
handle
mouse and touch events. Apps will receive mouse events AND touch
events.
Also, the precision of the mouse events will be incredibly lossy
due
to
integer truncation when compared with the touch events, which have
double
precision.
 Recommend removing this patch altogether.

 The patch in question is
http://hg.libsdl.org/SDL/raw-__rev/17ef8a7cab55
http://hg.libsdl.org/SDL/raw-rev/17ef8a7cab55
in file “src/video/android/SDL___androidtouch.c”
 -John


 _________________________________________________
 SDL mailing list
 SDL at lists.libsdl.org <mailto: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

slouken · December 2, 2012, 7:52am

In general, I think you only want to handle the mouse events, unless you’re
doing something that’s specifically touch sensitive, e.g. handling
gestures. The intent is that you can assume that any touch input will also
generate simulated mouse events if no mouse is present, so any
non-touch-specific UI elements will work consistently on platforms with
only mice as well as platforms with only touch input.

If you have a UI element that works better with touch input for some
reason, then as soon as you get touch input events you should reset your
state and start ignoring mouse input.

Looking at the event sequence it may make sense to send the touch events
first so you know the mouse events are coming. e.g.

FINGERDOWN
MOUSEMOTION
MOUSEBUTTONDOWN
FINGERMOTION ,MOUSEMOTION,… dozens of these pairs.
FINGERUP
MOUSEBUTTONUP

Cheers!On Sat, Dec 1, 2012 at 8:47 PM, John wrote:

Yes, sort of. It’s not important to me whether the events were truly
triggered by such-and-such device, although I can see why an app might need
that. I’d like to know how a “well behaved” app event loop should interpret
the new SDL events. Knowing that, I can revise my apps to follow suit.

Perhaps a real example would make more sense: A game displays a button
graphic. The player can “press” the on-screen button with a mouse down
event. They may also press the on-screen button with a finger event. The
app handles both events, and it handles the “up” events as well in order to
alter the button appearance. Just your typical “onmousedown/onmouseup” sort
of stuff. The code compiles nicely on all platforms that SDL supports. Now,
with the mouse emulation patch applied, on Android, when the user touches
the screen, the app recieves a flurry of mouse events AND touch events. The
mousemotion is even weirder, because the mouse emulation patch generates
very sudden, fast motion when there is no motion at all. On finger-down,
SDL moves the “fake” mouse location from it’s previously fake location to
the new finger location by generating a mouse motion event. Kinda like the
old WarpMouse call.

Here’s the event sequence on Android before the patch, when the user
touches the screen then releases:

FINGERDOWN
FINGERMOTION
FINGERMOTION… dozens of these.
FINGERUP

Here’s the event sequence after the emulation patch:

MOUSEMOTION
MOUSEBUTTONDOWN
FINGERDOWN
MOUSEMOTION,FINGERMOTION,… dozens of these pairs.
MOUSEBUTTONUP
FINGERUP

On 12/01/2012 10:08 PM, Sik the hedgehog wrote:
So you want to distinguish between cursor events caused by the mouse
and cursor events caused by touch, if I’m understanding right?
(honestly it should be called cursor, not mouse)

2012/12/1 John :
How will the app event handler know whether to ignore mouse events?

I think the issue is that now SDL is always in this emulation mode. It
generates fake mouse events whenever it sees touch events, then delivers
BOTH events to the app. From the perspective of an app’s event loop,
sometimes SDL_MouseEvent is really a mouse event, and sometimes it is a
duplicate of a touch event or a finger event.

I guess this is really a question of what an app event loop should look
like
now. Say an app’s event handler resembles this code,

case SDL_MOUSEBUTTONDOWN: handle_mousedown(); break;
case SDL_TOUCHBUTTONDOWN: handle_touchbuttondown(); break;
case SDL_FINGERDOWN: handle_fingerdown(); break;
case SDL_MOUSEMOTION: handle_mousemotion(); break;
case SDL_FINGERMOTION: handle_fingermotion(); break;
case SDL_MOUSEWHEEL: handle_mousewheel(); break;
…etc.

How would you recommend app developers revise their event handlers to
work
after the mouse emulation patch?

On 12/01/2012 05:17 PM, Sam Lantinga wrote:
This is a required feature for games that use gesture support as well as
mouse
interaction. If you prefer to use only touch events, can you ignore the
mouse
events?

On Thu, Nov 29, 2012 at 3:31 PM, John <john at puckerupgames.com <mailto:john at puckerupgames.com**>> wrote:
 Hi,

 The patch in the SDL trunk (listed below) breaks apps that
correctly
handle
mouse and touch events. Apps will receive mouse events AND touch
events.
Also, the precision of the mouse events will be incredibly lossy
due
to
integer truncation when compared with the touch events, which have
double
precision.
 Recommend removing this patch altogether.

 The patch in question is
http://hg.libsdl.org/SDL/raw-_**_rev/17ef8a7cab55 http://hg.libsdl.org/SDL/raw-__rev/17ef8a7cab55
<http://hg.libsdl.org/SDL/raw-**rev/17ef8a7cab55 http://hg.libsdl.org/SDL/raw-rev/17ef8a7cab55
 in file "src/video/android/SDL___**androidtouch.c"


 -John


 ______________________________**___________________
 SDL mailing list
 SDL at lists.libsdl.org <mailto: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

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

John5 · December 2, 2012, 8:04am

Dunno what you’re asking about?

Android apps that worked on both desktops and droids before this patch no longer
work because they will receive fake events in addition to actual events. I’d
like to know what the new event model is so I can fix my apps.

Well, I assume the idea behind the patch is so that programs that
weren’t designed for touch in the first place can act accordingly

Yes, I would assume the same judging by the commit message, and it’s a perfectly
reasonable thing to do for a portability layer. I defer to the patch author to
explain what the goal is. I am happy to revise my apps to fit the new SDL event
model, whatever that may be.

I guess it depends on whether you just want a barebones generic cursor
or want to handle touch gestures specifically.

I think what you are suggesting is that SDL_Mouse*Event now represents a
generic, higher level “input” event, and existing apps should be revised to only
handle mouse events, but ignore all the touch/finger events. If so, I’m ok with
that. I actually don’t care about barebones v. logical/virtual v. legacy
emulation layers. Barebones is fine by me. Logical events are fine by me.
Emulation is fine by me, too. Pick one and I can code to it! :)On 12/02/2012 01:08 AM, Sik the hedgehog wrote:

Well, I assume the idea behind the patch is so that programs that
weren’t designed for touch in the first place can act accordingly when
a touch screen is used (since again, those are really cursor events,
not mouse events - the name is a misnomer).

Dunno what you’re asking about? If you mean about handling the cursor
as-is, unless you’re handling specific gestures you should probably
use only the cursor events - though cursor events are quite barebones,
I had suggested a double click event some time ago (which could be
mapped to whatever is the touch equivalent).

I guess it depends on whether you just want a barebones generic cursor
or want to handle touch gestures specifically.

2012/12/2 John <@John5>:
Yes, sort of. It’s not important to me whether the events were truly
triggered by such-and-such device, although I can see why an app might need
that. I’d like to know how a “well behaved” app event loop should interpret
the new SDL events. Knowing that, I can revise my apps to follow suit.

Perhaps a real example would make more sense: A game displays a button
graphic. The player can “press” the on-screen button with a mouse down
event. They may also press the on-screen button with a finger event. The app
handles both events, and it handles the “up” events as well in order to
alter the button appearance. Just your typical “onmousedown/onmouseup” sort
of stuff. The code compiles nicely on all platforms that SDL supports. Now,
with the mouse emulation patch applied, on Android, when the user touches
the screen, the app recieves a flurry of mouse events AND touch events. The
mousemotion is even weirder, because the mouse emulation patch generates
very sudden, fast motion when there is no motion at all. On finger-down, SDL
moves the “fake” mouse location from it’s previously fake location to the
new finger location by generating a mouse motion event. Kinda like the old
WarpMouse call.

Here’s the event sequence on Android before the patch, when the user touches
the screen then releases:

FINGERDOWN
FINGERMOTION
FINGERMOTION… dozens of these.
FINGERUP

Here’s the event sequence after the emulation patch:

MOUSEMOTION
MOUSEBUTTONDOWN
FINGERDOWN
MOUSEMOTION,FINGERMOTION,… dozens of these pairs.
MOUSEBUTTONUP
FINGERUP

On 12/01/2012 10:08 PM, Sik the hedgehog wrote:
So you want to distinguish between cursor events caused by the mouse
and cursor events caused by touch, if I’m understanding right?
(honestly it should be called cursor, not mouse)

2012/12/1 John <@John5>:
How will the app event handler know whether to ignore mouse events?

I think the issue is that now SDL is always in this emulation mode. It
generates fake mouse events whenever it sees touch events, then delivers
BOTH events to the app. From the perspective of an app’s event loop,
sometimes SDL_MouseEvent is really a mouse event, and sometimes it is a
duplicate of a touch event or a finger event.

I guess this is really a question of what an app event loop should look
like
now. Say an app’s event handler resembles this code,
case SDL_MOUSEBUTTONDOWN: handle_mousedown(); break;
case SDL_TOUCHBUTTONDOWN: handle_touchbuttondown(); break;
case SDL_FINGERDOWN:      handle_fingerdown(); break;
case SDL_MOUSEMOTION:     handle_mousemotion(); break;
case SDL_FINGERMOTION:    handle_fingermotion(); break;
case SDL_MOUSEWHEEL:      handle_mousewheel(); break;
...etc.
How would you recommend app developers revise their event handlers to
work
after the mouse emulation patch?

On 12/01/2012 05:17 PM, Sam Lantinga wrote:
This is a required feature for games that use gesture support as well as
mouse
interaction. If you prefer to use only touch events, can you ignore the
mouse
events?

On Thu, Nov 29, 2012 at 3:31 PM, John <@John5 mailto:John5> wrote:
  Hi,

  The patch in the SDL trunk (listed below) breaks apps that
correctly
handle
mouse and touch events. Apps will receive mouse events AND touch
events.
Also, the precision of the mouse events will be incredibly lossy
due
to
integer truncation when compared with the touch events, which have
double
precision.
  Recommend removing this patch altogether.

  The patch in question is
http://hg.libsdl.org/SDL/raw-__rev/17ef8a7cab55
http://hg.libsdl.org/SDL/raw-rev/17ef8a7cab55
in file “src/video/android/SDL___androidtouch.c”
  -John


  _________________________________________________
  SDL mailing list
  SDL at lists.libsdl.org <mailto: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

Sik_the_hedgehog · December 2, 2012, 8:50am

2012/12/2 John :

Android apps that worked on both desktops and droids before this patch no
longer work because they will receive fake events in addition to actual
events. I’d like to know what the new event model is so I can fix my apps.

Can you be more specific about what breaks? Or better said, what kind
of problems it causes. Otherwise it’s going to be hard to tell what
could be a good solution, since as usual it depends on the situation.

I think what you are suggesting is that SDL_Mouse*Event now represents a
generic, higher level “input” event, and existing apps should be revised to
only handle mouse events, but ignore all the touch/finger events. If so, I’m
ok with that. I actually don’t care about barebones v. logical/virtual v.
legacy emulation layers. Barebones is fine by me. Logical events are fine by
me. Emulation is fine by me, too. Pick one and I can code to it!

Mouse events were always cursor events, calling them mouse events was
always a misnomer, it’s probably from when pretty much the only way
you would be likely to control the cursor was with a mouse. I know
Allegro has this same naming issue.

Again: those events are pretty barebones. No idea exactly how they’re
mapped (given I don’t have touch screens), but I assume the only two
things that really map are left click (start touching for click press,
stop touching for click release) and dragging (move the finger around
as you’re touching). It can’t handle multiple touches, let alone
gestures.

I suppose that what we really need is better cursor support in
general. Again, maybe it would be better if you could tell us exactly
what problems are caused to work around them meanwhile.

Sik_the_hedgehog · December 2, 2012, 9:41am

Is the order of the events guaranteed to come in that order, though?

2012/12/2 Sam Lantinga :>

In general, I think you only want to handle the mouse events, unless you’re
doing something that’s specifically touch sensitive, e.g. handling gestures.
The intent is that you can assume that any touch input will also generate
simulated mouse events if no mouse is present, so any non-touch-specific UI
elements will work consistently on platforms with only mice as well as
platforms with only touch input.

If you have a UI element that works better with touch input for some reason,
then as soon as you get touch input events you should reset your state and
start ignoring mouse input.

Looking at the event sequence it may make sense to send the touch events
first so you know the mouse events are coming. e.g.

FINGERDOWN
MOUSEMOTION
MOUSEBUTTONDOWN
FINGERMOTION ,MOUSEMOTION,… dozens of these pairs.
FINGERUP
MOUSEBUTTONUP

Cheers!

On Sat, Dec 1, 2012 at 8:47 PM, John wrote:
Yes, sort of. It’s not important to me whether the events were truly
triggered by such-and-such device, although I can see why an app might need
that. I’d like to know how a “well behaved” app event loop should interpret
the new SDL events. Knowing that, I can revise my apps to follow suit.

Perhaps a real example would make more sense: A game displays a button
graphic. The player can “press” the on-screen button with a mouse down
event. They may also press the on-screen button with a finger event. The app
handles both events, and it handles the “up” events as well in order to
alter the button appearance. Just your typical “onmousedown/onmouseup” sort
of stuff. The code compiles nicely on all platforms that SDL supports. Now,
with the mouse emulation patch applied, on Android, when the user touches
the screen, the app recieves a flurry of mouse events AND touch events. The
mousemotion is even weirder, because the mouse emulation patch generates
very sudden, fast motion when there is no motion at all. On finger-down, SDL
moves the “fake” mouse location from it’s previously fake location to the
new finger location by generating a mouse motion event. Kinda like the old
WarpMouse call.

Here’s the event sequence on Android before the patch, when the user
touches the screen then releases:

FINGERDOWN
FINGERMOTION
FINGERMOTION… dozens of these.
FINGERUP

Here’s the event sequence after the emulation patch:

MOUSEMOTION
MOUSEBUTTONDOWN
FINGERDOWN
MOUSEMOTION,FINGERMOTION,… dozens of these pairs.
MOUSEBUTTONUP
FINGERUP

On 12/01/2012 10:08 PM, Sik the hedgehog wrote:
So you want to distinguish between cursor events caused by the mouse
and cursor events caused by touch, if I’m understanding right?
(honestly it should be called cursor, not mouse)

2012/12/1 John :
How will the app event handler know whether to ignore mouse events?

I think the issue is that now SDL is always in this emulation mode. It
generates fake mouse events whenever it sees touch events, then delivers
BOTH events to the app. From the perspective of an app’s event loop,
sometimes SDL_MouseEvent is really a mouse event, and sometimes it is a
duplicate of a touch event or a finger event.

I guess this is really a question of what an app event loop should look
like
now. Say an app’s event handler resembles this code,

case SDL_MOUSEBUTTONDOWN: handle_mousedown(); break;
case SDL_TOUCHBUTTONDOWN: handle_touchbuttondown(); break;
case SDL_FINGERDOWN: handle_fingerdown(); break;
case SDL_MOUSEMOTION: handle_mousemotion(); break;
case SDL_FINGERMOTION: handle_fingermotion(); break;
case SDL_MOUSEWHEEL: handle_mousewheel(); break;
…etc.

How would you recommend app developers revise their event handlers to
work
after the mouse emulation patch?

On 12/01/2012 05:17 PM, Sam Lantinga wrote:
This is a required feature for games that use gesture support as well
as
mouse
interaction. If you prefer to use only touch events, can you ignore
the
mouse
events?

On Thu, Nov 29, 2012 at 3:31 PM, John <john at puckerupgames.com <mailto:john at puckerupgames.com>> wrote:
 Hi,

 The patch in the SDL trunk (listed below) breaks apps that
correctly
handle
mouse and touch events. Apps will receive mouse events AND touch
events.
Also, the precision of the mouse events will be incredibly lossy
due
to
integer truncation when compared with the touch events, which have
double
precision.
 Recommend removing this patch altogether.

 The patch in question is
http://hg.libsdl.org/SDL/raw-__rev/17ef8a7cab55
http://hg.libsdl.org/SDL/raw-rev/17ef8a7cab55
in file “src/video/android/SDL___androidtouch.c”
 -John


 _________________________________________________
 SDL mailing list
 SDL at lists.libsdl.org <mailto: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

John5 · December 2, 2012, 9:08pm

The intent is that you can assume that any touch input will also generate
simulated mouse events if no mouse is present,

The patch appears to always generate mouse events whether or not the user has
connected a mouse to their android device.

Here’s one solution: SDL could expose an API so that apps could query SDL to
find out whether or not SDL is generating artificial events. A similar solution
would be for SDL to set a bit in the SDL_MouseEvent and SDL_MouseMotion event
structs to inform the app the given event is artificial.

In general, I think you only want to handle the mouse events, unless you’re
doing something that’s specifically touch sensitive, e.g. handling gestures

I think it’s safe to assume that modern game developers wish to support gestures
and multiple touch points, rather than the single-mouse/cursor input model.On 12/02/2012 02:52 AM, Sam Lantinga wrote:

In general, I think you only want to handle the mouse events, unless you’re
doing something that’s specifically touch sensitive, e.g. handling gestures.
The intent is that you can assume that any touch input will also generate
simulated mouse events if no mouse is present, so any non-touch-specific UI
elements will work consistently on platforms with only mice as well as platforms
with only touch input.

If you have a UI element that works better with touch input for some reason,
then as soon as you get touch input events you should reset your state and start
ignoring mouse input.

Looking at the event sequence it may make sense to send the touch events first
so you know the mouse events are coming. e.g.

FINGERDOWN
MOUSEMOTION
MOUSEBUTTONDOWN
FINGERMOTION ,MOUSEMOTION,… dozens of these pairs.
FINGERUP
MOUSEBUTTONUP

Cheers!

On Sat, Dec 1, 2012 at 8:47 PM, John <@John5 mailto:John5> wrote:

Yes, sort of.  It's not important to me whether the events were truly
triggered by such-and-such device, although I can see why an app might need
that. I'd like to know how a "well behaved" app event loop should interpret
the new SDL events. Knowing that, I can revise my apps to follow suit.

Perhaps a real example would make more sense: A game displays a button
graphic. The player can "press" the on-screen button with a mouse down
event. They may also press the on-screen button with a finger event. The app
handles both events, and it handles the "up" events as well in order to
alter the button appearance. Just your typical "onmousedown/onmouseup" sort
of stuff. The code compiles nicely on all platforms that SDL supports. Now,
with the mouse emulation patch applied, on Android, when the user touches
the screen, the app recieves a flurry of mouse events AND touch events. The
mousemotion is even weirder, because the mouse emulation patch generates
very sudden, fast motion when there is no motion at all. On finger-down, SDL
moves the "fake" mouse location from it's previously fake location to the
new finger location by generating a mouse motion event. Kinda like the old
WarpMouse call.

Here's the event sequence on Android before the patch, when the user touches
the screen then releases:

FINGERDOWN
FINGERMOTION
FINGERMOTION... dozens of these.
FINGERUP

Here's the event sequence after the emulation patch:

MOUSEMOTION
MOUSEBUTTONDOWN
FINGERDOWN
MOUSEMOTION,FINGERMOTION,.. dozens of these pairs.
MOUSEBUTTONUP
FINGERUP





On 12/01/2012 10:08 PM, Sik the hedgehog wrote:

    So you want to distinguish between cursor events caused by the mouse
    and cursor events caused by touch, if I'm understanding right?
    (honestly it should be called cursor, not mouse)

    2012/12/1 John <@John5 <mailto:@John5>>:

        How will the app event handler know whether to ignore mouse events?

        I think the issue is that now SDL is always in this emulation mode. It
        generates fake mouse events whenever it sees touch events, then delivers
        BOTH events to the app. From the perspective of an app's event loop,
        sometimes SDL_MouseEvent is really a mouse event, and sometimes it is a
        duplicate of a touch event or a finger event.

        I guess this is really a question of what an app event loop should
        look like
        now. Say an app's event handler resembles this code,

            case SDL_MOUSEBUTTONDOWN: handle_mousedown(); break;
            case SDL_TOUCHBUTTONDOWN: handle_touchbuttondown(); break;
            case SDL_FINGERDOWN:      handle_fingerdown(); break;
            case SDL_MOUSEMOTION:     handle_mousemotion(); break;
            case SDL_FINGERMOTION:    handle_fingermotion(); break;
            case SDL_MOUSEWHEEL:      handle_mousewheel(); break;
            ...etc.

        How would you recommend app developers revise their event handlers
        to work
        after the mouse emulation patch?




        On 12/01/2012 05:17 PM, Sam Lantinga wrote:


            This is a required feature for games that use gesture support as
            well as
            mouse
            interaction.  If you prefer to use only touch events, can you
            ignore the
            mouse
            events?

            On Thu, Nov 29, 2012 at 3:31 PM, John <@John5 <mailto:@John5> <mailto:@John5 <mailto:@John5>__>> wrote:

                  Hi,

                  The patch in the SDL trunk (listed below) breaks apps that
            correctly
            handle
                  mouse and touch events. Apps will receive mouse events AND
            touch
            events.
                  Also, the precision of the mouse events will be incredibly
            lossy due
            to
                  integer truncation when compared with the touch events,
            which have
            double
                  precision.

                  Recommend removing this patch altogether.

                  The patch in question is
            http://hg.libsdl.org/SDL/raw-____rev/17ef8a7cab55
            <http://hg.libsdl.org/SDL/raw-__rev/17ef8a7cab55>
                  <http://hg.libsdl.org/SDL/raw-__rev/17ef8a7cab55
            <http://hg.libsdl.org/SDL/raw-rev/17ef8a7cab55>>
                  in file "src/video/android/SDL_____androidtouch.c"


                  -John


                  ___________________________________________________
                  SDL mailing list
            SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
            <mailto:SDL at lists.libsdl.org <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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

John5 · December 2, 2012, 9:56pm

Can you be more specific about what breaks?

Sure. For example, imagine code which handles SDL_MOUSEMOTION and
SDL_FINGERMOTION. Say it detects a traditional “mouse drag” or a contemporary
"fling" of an on-screen object.

case SDL_MOUSEMOTION:
     if (is_inside(obj, evt) && is_pressed (evt)){
         vx = evt.motion.xrel/dt;
         vy = evt.motion.yrel/dt;
         accelerate_fling (obj, vx, vy);
     }
     break;

case SDL_FINGERMOTION:
     if (is_inside(obj, evt) && is_pressed (evt)){
         SDL_Touch* tch = SDL_GetTouch(evt.tfinger.touchId);
         vx = (evt.tfinger.dx  * window.w/tch->xres)/dt;
         vy = (evt.tfinger.dy  * window.h/tch->yres)/dt;
         accelerate_fling (obj, vx, vy);
     }
     break;

Before the patch, the player can drag the object with a mouse or with a finger.
It doesn’t matter which. It works on all platforms. After the patch, the app
will sometimes receive duplicate (but not identical) events, first the
artificial mouse event, followed by the fingermotion event. The app sees an
artificial mousemotion with a vector whose x-component has magnitude xrel in
the direction of SIGN(xrel). Then it sees a finger motion with a similar vector.
The app doesn’t know whether the mouse event is artificial, so it must handle
both if it wishes to support touch devices at all. The result here is that the
app will over-accelerate the object.On 12/02/2012 03:50 AM, Sik the hedgehog wrote:

2012/12/2 John <@John5>:

Android apps that worked on both desktops and droids before this patch no
longer work because they will receive fake events in addition to actual
events. I’d like to know what the new event model is so I can fix my apps.

Can you be more specific about what breaks? Or better said, what kind
of problems it causes. Otherwise it’s going to be hard to tell what
could be a good solution, since as usual it depends on the situation.

I think what you are suggesting is that SDL_Mouse*Event now represents a
generic, higher level “input” event, and existing apps should be revised to
only handle mouse events, but ignore all the touch/finger events. If so, I’m
ok with that. I actually don’t care about barebones v. logical/virtual v.
legacy emulation layers. Barebones is fine by me. Logical events are fine by
me. Emulation is fine by me, too. Pick one and I can code to it!

Mouse events were always cursor events, calling them mouse events was
always a misnomer, it’s probably from when pretty much the only way
you would be likely to control the cursor was with a mouse. I know
Allegro has this same naming issue.

Again: those events are pretty barebones. No idea exactly how they’re
mapped (given I don’t have touch screens), but I assume the only two
things that really map are left click (start touching for click press,
stop touching for click release) and dragging (move the finger around
as you’re touching). It can’t handle multiple touches, let alone
gestures.

I suppose that what we really need is better cursor support in
general. Again, maybe it would be better if you could tell us exactly
what problems are caused to work around them meanwhile.

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

slouken · December 2, 2012, 10:50pm

Oh interesting, is there any way to tell if a mouse is connected? I don’t
think we have any way of generating real mouse events on Android right
now… ?On Sun, Dec 2, 2012 at 1:08 PM, John wrote:

The intent is that you can assume that any touch input will also generate
simulated mouse events if no mouse is present,

The patch appears to always generate mouse events whether or not the user
has connected a mouse to their android device.

Here’s one solution: SDL could expose an API so that apps could query SDL
to find out whether or not SDL is generating artificial events. A similar
solution would be for SDL to set a bit in the SDL_MouseEvent and
SDL_MouseMotion event structs to inform the app the given event is
artificial.

In general, I think you only want to handle the mouse events, unless
you’re
doing something that’s specifically touch sensitive, e.g. handling
gestures

I think it’s safe to assume that modern game developers wish to support
gestures and multiple touch points, rather than the single-mouse/cursor
input model.

On 12/02/2012 02:52 AM, Sam Lantinga wrote:
In general, I think you only want to handle the mouse events, unless
you’re
doing something that’s specifically touch sensitive, e.g. handling
gestures.
The intent is that you can assume that any touch input will also
generate
simulated mouse events if no mouse is present, so any non-touch-specific
UI
elements will work consistently on platforms with only mice as well as
platforms
with only touch input.

If you have a UI element that works better with touch input for some
reason,
then as soon as you get touch input events you should reset your state
and start
ignoring mouse input.

Looking at the event sequence it may make sense to send the touch events
first
so you know the mouse events are coming. e.g.

FINGERDOWN
MOUSEMOTION
MOUSEBUTTONDOWN
FINGERMOTION ,MOUSEMOTION,… dozens of these pairs.
FINGERUP
MOUSEBUTTONUP

Cheers!

On Sat, Dec 1, 2012 at 8:47 PM, John <john at puckerupgames.com <mailto:john at puckerupgames.com**>> wrote:
Yes, sort of.  It's not important to me whether the events were truly
triggered by such-and-such device, although I can see why an app
might need
that. I’d like to know how a “well behaved” app event loop should
interpret
the new SDL events. Knowing that, I can revise my apps to follow suit.
Perhaps a real example would make more sense: A game displays a button
graphic. The player can "press" the on-screen button with a mouse down
event. They may also press the on-screen button with a finger event.
The app
handles both events, and it handles the “up” events as well in order
to
alter the button appearance. Just your typical
"onmousedown/onmouseup" sort
of stuff. The code compiles nicely on all platforms that SDL
supports. Now,
with the mouse emulation patch applied, on Android, when the user
touches
the screen, the app recieves a flurry of mouse events AND touch
events. The
mousemotion is even weirder, because the mouse emulation patch
generates
very sudden, fast motion when there is no motion at all. On
finger-down, SDL
moves the “fake” mouse location from it’s previously fake location to
the
new finger location by generating a mouse motion event. Kinda like
the old
WarpMouse call.
Here's the event sequence on Android before the patch, when the user
touches
the screen then releases:
FINGERDOWN
FINGERMOTION
FINGERMOTION... dozens of these.
FINGERUP

Here's the event sequence after the emulation patch:

MOUSEMOTION
MOUSEBUTTONDOWN
FINGERDOWN
MOUSEMOTION,FINGERMOTION,.. dozens of these pairs.
MOUSEBUTTONUP
FINGERUP





On 12/01/2012 10:08 PM, Sik the hedgehog wrote:

    So you want to distinguish between cursor events caused by the
mouse
and cursor events caused by touch, if I’m understanding right?
(honestly it should be called cursor, not mouse)
    2012/12/1 John <john at puckerupgames.com <mailto:
john at puckerupgames.com**>>:
        How will the app event handler know whether to ignore mouse
events?
        I think the issue is that now SDL is always in this emulation
mode. It
generates fake mouse events whenever it sees touch events,
then delivers
BOTH events to the app. From the perspective of an app’s
event loop,
sometimes SDL_MouseEvent is really a mouse event, and
sometimes it is a
duplicate of a touch event or a finger event.
        I guess this is really a question of what an app event loop
should
look like
now. Say an app’s event handler resembles this code,
            case SDL_MOUSEBUTTONDOWN: handle_mousedown(); break;
            case SDL_TOUCHBUTTONDOWN: handle_touchbuttondown(); break;
            case SDL_FINGERDOWN:      handle_fingerdown(); break;
            case SDL_MOUSEMOTION:     handle_mousemotion(); break;
            case SDL_FINGERMOTION:    handle_fingermotion(); break;
            case SDL_MOUSEWHEEL:      handle_mousewheel(); break;
            ...etc.

        How would you recommend app developers revise their event
handlers
to work
after the mouse emulation patch?
        On 12/01/2012 05:17 PM, Sam Lantinga wrote:


            This is a required feature for games that use gesture
support as
well as
mouse
interaction. If you prefer to use only touch events, can
you
ignore the
mouse
events?
            On Thu, Nov 29, 2012 at 3:31 PM, John < john at puckerupgames.com <mailto:john at puckerupgames.com**> <mailto:john at puckerupgames.com <mailto:john at puckerupgames.com**>__>> wrote:

                  Hi,

                  The patch in the SDL trunk (listed below) breaks
apps that
correctly
handle
mouse and touch events. Apps will receive mouse
events AND
touch
events.
Also, the precision of the mouse events will be
incredibly
lossy due
to
integer truncation when compared with the touch
events,
which have
double
precision.
                  Recommend removing this patch altogether.

                  The patch in question is
            http://hg.libsdl.org/SDL/raw-_**___rev/17ef8a7cab55<http://hg.libsdl.org/SDL/raw-____rev/17ef8a7cab55>
            <http://hg.libsdl.org/SDL/raw-**__rev/17ef8a7cab55<http://hg.libsdl.org/SDL/raw-__rev/17ef8a7cab55>
                  <http://hg.libsdl.org/SDL/raw-**__rev/17ef8a7cab55<http://hg.libsdl.org/SDL/raw-__rev/17ef8a7cab55>
            <http://hg.libsdl.org/SDL/raw-**rev/17ef8a7cab55<http://hg.libsdl.org/SDL/raw-rev/17ef8a7cab55>
                  in file "src/video/android/SDL_____**
androidtouch.c"
                  -John


                  ______________________________**
                  SDL mailing list
            SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
            <mailto:SDL at lists.libsdl.org <mailto: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>
                  <http://lists.libsdl.org/__**
listinfo.cgi/sdl-libsdl.orghttp://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 <mailto: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 <mailto: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 <mailto: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 <mailto: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

Sik_the_hedgehog · December 3, 2012, 3:42am

A similar
solution would be for SDL to set a bit in the SDL_MouseEvent and
SDL_MouseMotion event structs to inform the app the given event is
artificial.

Even better, indicate which device generated the event. This could
also become useful if SDL decides to support multiple mouses using the
same API, or even better, if new devices appear that aren’t mouses or
touch screens but also generate cursor events - a single bit can’t let
you know what kind of device generated it, just distinguish between
two of them.

Pallav_Nawani · December 24, 2012, 7:39am

We could have an SDL_HINT to tell SDL not to send duplicate mouse events…On 03-12-2012 04:20, Sam Lantinga wrote:

Oh interesting, is there any way to tell if a mouse is connected? I
don’t think we have any way of generating real mouse events on Android
right now… ?

On Sun, Dec 2, 2012 at 1:08 PM, John <john at puckerupgames.com <mailto:john at puckerupgames.com>> wrote:

> The intent is that you can assume that any touch input will also
generate
> simulated mouse events if no mouse is present,

The patch appears to always generate mouse events whether or not
the user has connected a mouse to their android device.


Here's one solution:  SDL could expose an API so that apps could
query SDL to find out whether or not SDL is generating artificial
events. A similar solution would be for SDL to set a bit in the
SDL_MouseEvent and SDL_MouseMotion event structs to inform the app
the given event is artificial.



> In general, I think you only want to handle the mouse events,
unless you're
> doing something that's specifically touch sensitive, e.g.
handling gestures

I think it's safe to assume that modern game developers wish to
support gestures and multiple touch points, rather than the
single-mouse/cursor input model.





On 12/02/2012 02:52 AM, Sam Lantinga wrote:


    In general, I think you only want to handle the mouse events,
    unless you're
    doing something that's specifically touch sensitive, e.g.
    handling gestures.
      The intent is that you can assume that any touch input will
    also generate
    simulated mouse events if no mouse is present, so any
    non-touch-specific UI
    elements will work consistently on platforms with only mice as
    well as platforms
    with only touch input.

    If you have a UI element that works better with touch input
    for some reason,
    then as soon as you get touch input events you should reset
    your state and start
    ignoring mouse input.

    Looking at the event sequence it may make sense to send the
    touch events first
    so you know the mouse events are coming. e.g.

    FINGERDOWN
    MOUSEMOTION
    MOUSEBUTTONDOWN
    FINGERMOTION ,MOUSEMOTION,... dozens of these pairs.
    FINGERUP
    MOUSEBUTTONUP

    Cheers!

    On Sat, Dec 1, 2012 at 8:47 PM, John <john at puckerupgames.com <mailto:john at puckerupgames.com> <mailto:john at puckerupgames.com <mailto:john at puckerupgames.com>>> wrote:

        Yes, sort of.  It's not important to me whether the events
    were truly
        triggered by such-and-such device, although I can see why
    an app might need
        that. I'd like to know how a "well behaved" app event loop
    should interpret
        the new SDL events. Knowing that, I can revise my apps to
    follow suit.

        Perhaps a real example would make more sense: A game
    displays a button
        graphic. The player can "press" the on-screen button with
    a mouse down
        event. They may also press the on-screen button with a
    finger event. The app
        handles both events, and it handles the "up" events as
    well in order to
        alter the button appearance. Just your typical
    "onmousedown/onmouseup" sort
        of stuff. The code compiles nicely on all platforms that
    SDL supports. Now,
        with the mouse emulation patch applied, on Android, when
    the user touches
        the screen, the app recieves a flurry of mouse events AND
    touch events. The
        mousemotion is even weirder, because the mouse emulation
    patch generates
        very sudden, fast motion when there is no motion at all.
    On finger-down, SDL
        moves the "fake" mouse location from it's previously fake
    location to the
        new finger location by generating a mouse motion event.
    Kinda like the old
        WarpMouse call.

        Here's the event sequence on Android before the patch,
    when the user touches
        the screen then releases:

        FINGERDOWN
        FINGERMOTION
        FINGERMOTION... dozens of these.
        FINGERUP

        Here's the event sequence after the emulation patch:

        MOUSEMOTION
        MOUSEBUTTONDOWN
        FINGERDOWN
        MOUSEMOTION,FINGERMOTION,.. dozens of these pairs.
        MOUSEBUTTONUP
        FINGERUP





        On 12/01/2012 10:08 PM, Sik the hedgehog wrote:

            So you want to distinguish between cursor events
    caused by the mouse
            and cursor events caused by touch, if I'm
    understanding right?
            (honestly it should be called cursor, not mouse)

            2012/12/1 John <john at puckerupgames.com
    <mailto:john at puckerupgames.com> <mailto:john at puckerupgames.com
    <mailto:john at puckerupgames.com>>>:


                How will the app event handler know whether to
    ignore mouse events?

                I think the issue is that now SDL is always in
    this emulation mode. It
                generates fake mouse events whenever it sees touch
    events, then delivers
                BOTH events to the app. From the perspective of an
    app's event loop,
                sometimes SDL_MouseEvent is really a mouse event,
    and sometimes it is a
                duplicate of a touch event or a finger event.

                I guess this is really a question of what an app
    event loop should
                look like
                now. Say an app's event handler resembles this code,

                    case SDL_MOUSEBUTTONDOWN: handle_mousedown();
    break;
                    case SDL_TOUCHBUTTONDOWN:
    handle_touchbuttondown(); break;
                    case SDL_FINGERDOWN:  handle_fingerdown(); break;
                    case SDL_MOUSEMOTION: handle_mousemotion(); break;
                    case SDL_FINGERMOTION:  handle_fingermotion();
    break;
                    case SDL_MOUSEWHEEL:  handle_mousewheel(); break;
                    ...etc.

                How would you recommend app developers revise
    their event handlers
                to work
                after the mouse emulation patch?




                On 12/01/2012 05:17 PM, Sam Lantinga wrote:


                    This is a required feature for games that use
    gesture support as
                    well as
                    mouse
                    interaction.  If you prefer to use only touch
    events, can you
                    ignore the
                    mouse
                    events?

                    On Thu, Nov 29, 2012 at 3:31 PM, John <john at puckerupgames.com <mailto:john at puckerupgames.com> <mailto:john at puckerupgames.com <mailto:john at puckerupgames.com>> <mailto:john at puckerupgames.com <mailto:john at puckerupgames.com> <mailto:john at puckerupgames.com <mailto:john at puckerupgames.com>>__>> wrote:

                          Hi,

                          The patch in the SDL trunk (listed
    below) breaks apps that
                    correctly
                    handle
                          mouse and touch events. Apps will
    receive mouse events AND
                    touch
                    events.
                          Also, the precision of the mouse events
    will be incredibly
                    lossy due
                    to
                          integer truncation when compared with
    the touch events,
                    which have
                    double
                          precision.

                          Recommend removing this patch altogether.

                          The patch in question is
    http://hg.libsdl.org/SDL/raw-____rev/17ef8a7cab55
                    <http://hg.libsdl.org/SDL/raw-__rev/17ef8a7cab55>
                         
    <http://hg.libsdl.org/SDL/raw-__rev/17ef8a7cab55
                    <http://hg.libsdl.org/SDL/raw-rev/17ef8a7cab55>>
                          in file
    "src/video/android/SDL_____androidtouch.c"


                          -John


                         
    ___________________________________________________

                          SDL mailing list
    SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
    <mailto:SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>>
                    <mailto:SDL at lists.libsdl.org
    <mailto:SDL at lists.libsdl.org> <mailto:SDL at lists.libsdl.org
    <mailto: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 <mailto:SDL at lists.libsdl.org>
    <mailto:SDL at lists.libsdl.org <mailto: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 <mailto:SDL at lists.libsdl.org>
    <mailto:SDL at lists.libsdl.org <mailto: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 <mailto:SDL at lists.libsdl.org>
    <mailto:SDL at lists.libsdl.org <mailto: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 <mailto:SDL at lists.libsdl.org>
    <mailto:SDL at lists.libsdl.org <mailto: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 <mailto:SDL at lists.libsdl.org>
    http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto: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

–
Pallav Nawani
Game Designer/CEO
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming

slouken · December 24, 2012, 7:21pm

That’s a good idea. Want to make a patch for it?On Sun, Dec 23, 2012 at 11:39 PM, Pallav Nawani wrote:

We could have an SDL_HINT to tell SDL not to send duplicate mouse events…

On 03-12-2012 04:20, Sam Lantinga wrote:

Oh interesting, is there any way to tell if a mouse is connected? I
don’t think we have any way of generating real mouse events on Android
right now… ?

On Sun, Dec 2, 2012 at 1:08 PM, John <john at puckerupgames.com <mailto: john at puckerupgames.com**>> wrote:

> The intent is that you can assume that any touch input will also
generate
> simulated mouse events if no mouse is present,

The patch appears to always generate mouse events whether or not
the user has connected a mouse to their android device.


Here's one solution:  SDL could expose an API so that apps could
query SDL to find out whether or not SDL is generating artificial
events. A similar solution would be for SDL to set a bit in the
SDL_MouseEvent and SDL_MouseMotion event structs to inform the app
the given event is artificial.



> In general, I think you only want to handle the mouse events,
unless you're
> doing something that's specifically touch sensitive, e.g.
handling gestures

I think it's safe to assume that modern game developers wish to
support gestures and multiple touch points, rather than the
single-mouse/cursor input model.





On 12/02/2012 02:52 AM, Sam Lantinga wrote:


    In general, I think you only want to handle the mouse events,
    unless you're
    doing something that's specifically touch sensitive, e.g.
    handling gestures.
      The intent is that you can assume that any touch input will
    also generate
    simulated mouse events if no mouse is present, so any
    non-touch-specific UI
    elements will work consistently on platforms with only mice as
    well as platforms
    with only touch input.

    If you have a UI element that works better with touch input
    for some reason,
    then as soon as you get touch input events you should reset
    your state and start
    ignoring mouse input.

    Looking at the event sequence it may make sense to send the
    touch events first
    so you know the mouse events are coming. e.g.

    FINGERDOWN
    MOUSEMOTION
    MOUSEBUTTONDOWN
    FINGERMOTION ,MOUSEMOTION,... dozens of these pairs.
    FINGERUP
    MOUSEBUTTONUP

    Cheers!

    On Sat, Dec 1, 2012 at 8:47 PM, John <john at puckerupgames.com <mailto:john at puckerupgames.com**> <mailto:john at puckerupgames.com <mailto:john at puckerupgames.com**>>> wrote:

        Yes, sort of.  It's not important to me whether the events
    were truly
        triggered by such-and-such device, although I can see why
    an app might need
        that. I'd like to know how a "well behaved" app event loop
    should interpret
        the new SDL events. Knowing that, I can revise my apps to
    follow suit.

        Perhaps a real example would make more sense: A game
    displays a button
        graphic. The player can "press" the on-screen button with
    a mouse down
        event. They may also press the on-screen button with a
    finger event. The app
        handles both events, and it handles the "up" events as
    well in order to
        alter the button appearance. Just your typical
    "onmousedown/onmouseup" sort
        of stuff. The code compiles nicely on all platforms that
    SDL supports. Now,
        with the mouse emulation patch applied, on Android, when
    the user touches
        the screen, the app recieves a flurry of mouse events AND
    touch events. The
        mousemotion is even weirder, because the mouse emulation
    patch generates
        very sudden, fast motion when there is no motion at all.
    On finger-down, SDL
        moves the "fake" mouse location from it's previously fake
    location to the
        new finger location by generating a mouse motion event.
    Kinda like the old
        WarpMouse call.

        Here's the event sequence on Android before the patch,
    when the user touches
        the screen then releases:

        FINGERDOWN
        FINGERMOTION
        FINGERMOTION... dozens of these.
        FINGERUP

        Here's the event sequence after the emulation patch:

        MOUSEMOTION
        MOUSEBUTTONDOWN
        FINGERDOWN
        MOUSEMOTION,FINGERMOTION,.. dozens of these pairs.
        MOUSEBUTTONUP
        FINGERUP





        On 12/01/2012 10:08 PM, Sik the hedgehog wrote:

            So you want to distinguish between cursor events
    caused by the mouse
            and cursor events caused by touch, if I'm
    understanding right?
            (honestly it should be called cursor, not mouse)

            2012/12/1 John <john at puckerupgames.com
    <mailto:john at puckerupgames.com**> <mailto:john at puckerupgames.com

    <mailto:john at puckerupgames.com**>>>:


                How will the app event handler know whether to
    ignore mouse events?

                I think the issue is that now SDL is always in
    this emulation mode. It
                generates fake mouse events whenever it sees touch
    events, then delivers
                BOTH events to the app. From the perspective of an
    app's event loop,
                sometimes SDL_MouseEvent is really a mouse event,
    and sometimes it is a
                duplicate of a touch event or a finger event.

                I guess this is really a question of what an app
    event loop should
                look like
                now. Say an app's event handler resembles this code,

                    case SDL_MOUSEBUTTONDOWN: handle_mousedown();
    break;
                    case SDL_TOUCHBUTTONDOWN:
    handle_touchbuttondown(); break;
                    case SDL_FINGERDOWN:  handle_fingerdown(); break;
                    case SDL_MOUSEMOTION: handle_mousemotion(); break;
                    case SDL_FINGERMOTION:  handle_fingermotion();
    break;
                    case SDL_MOUSEWHEEL:  handle_mousewheel(); break;
                    ...etc.

                How would you recommend app developers revise
    their event handlers
                to work
                after the mouse emulation patch?




                On 12/01/2012 05:17 PM, Sam Lantinga wrote:


                    This is a required feature for games that use
    gesture support as
                    well as
                    mouse
                    interaction.  If you prefer to use only touch
    events, can you
                    ignore the
                    mouse
                    events?

                    On Thu, Nov 29, 2012 at 3:31 PM, John <john at puckerupgames.com <mailto:john at puckerupgames.com**> <mailto:john at puckerupgames.com <mailto:john at puckerupgames.com**>> <mailto:john at puckerupgames.com <mailto:john at puckerupgames.com**> <mailto:john at puckerupgames.com <mailto:john at puckerupgames.com**>>__>> wrote:

                          Hi,

                          The patch in the SDL trunk (listed
    below) breaks apps that
                    correctly
                    handle
                          mouse and touch events. Apps will
    receive mouse events AND
                    touch
                    events.
                          Also, the precision of the mouse events
    will be incredibly
                    lossy due
                    to
                          integer truncation when compared with
    the touch events,
                    which have
                    double
                          precision.

                          Recommend removing this patch altogether.

                          The patch in question is
    http://hg.libsdl.org/SDL/raw-_**___rev/17ef8a7cab55<http://hg.libsdl.org/SDL/raw-____rev/17ef8a7cab55>
                    <http://hg.libsdl.org/SDL/raw-**

__rev/17ef8a7cab55 http://hg.libsdl.org/SDL/raw-__rev/17ef8a7cab55>
<http://hg.libsdl.org/SDL/raw-**
__rev/17ef8a7cab55 http://hg.libsdl.org/SDL/raw-__rev/17ef8a7cab55
<http://hg.libsdl.org/SDL/raw-**rev/17ef8a7cab55 http://hg.libsdl.org/SDL/raw-rev/17ef8a7cab55

                          in file
    "src/video/android/SDL_____**androidtouch.c"


                          -John


                                 ______________________________**

                          SDL mailing list
    SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
    <mailto:SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>>
                    <mailto:SDL at lists.libsdl.org
    <mailto:SDL at lists.libsdl.org> <mailto:SDL at lists.libsdl.org
    <mailto: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.orghttp://lists.libsdl.org/__listinfo.cgi/sdl-libsdl.org

                                 <http://lists.libsdl.org/__**

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

                    ______________________________**

                    SDL mailing list
    SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
    <mailto:SDL at lists.libsdl.org <mailto: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.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

                ______________________________**___________________
                SDL mailing list
    SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
    <mailto:SDL at lists.libsdl.org <mailto: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.orghttp://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

            ______________________________**___________________
            SDL mailing list
    SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
    <mailto:SDL at lists.libsdl.org <mailto: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 <mailto:SDL at lists.libsdl.org>
    <mailto:SDL at lists.libsdl.org <mailto: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 <mailto: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 <mailto: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

–
Pallav Nawani
Game Designer/CEO
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_**Gaming http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/**Ironcode.Gaming http://www.facebook.com/Ironcode.Gaming

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

Pallav_Nawani · December 26, 2012, 7:51am

Sure thing. :)On 25-12-2012 00:51, Sam Lantinga wrote:

That’s a good idea. Want to make a patch for it?

On Sun, Dec 23, 2012 at 11:39 PM, Pallav Nawani <@Pallav_Nawani mailto:Pallav_Nawani> wrote:

We could have an SDL_HINT to tell SDL not to send duplicate mouse
events...


On 03-12-2012 04:20, Sam Lantinga wrote:

    Oh interesting, is there any way to tell if a mouse is
    connected?  I don't think we have any way of generating real
    mouse events on Android right now... ?

    On Sun, Dec 2, 2012 at 1:08 PM, John <john at puckerupgames.com <mailto:john at puckerupgames.com> <mailto:john at puckerupgames.com <mailto:john at puckerupgames.com>>> wrote:

        > The intent is that you can assume that any touch input
    will also
        generate
        > simulated mouse events if no mouse is present,

        The patch appears to always generate mouse events whether
    or not
        the user has connected a mouse to their android device.


        Here's one solution:  SDL could expose an API so that apps
    could
        query SDL to find out whether or not SDL is generating
    artificial
        events. A similar solution would be for SDL to set a bit
    in the
        SDL_MouseEvent and SDL_MouseMotion event structs to inform
    the app
        the given event is artificial.



        > In general, I think you only want to handle the mouse
    events,
        unless you're
        > doing something that's specifically touch sensitive, e.g.
        handling gestures

        I think it's safe to assume that modern game developers
    wish to
        support gestures and multiple touch points, rather than the
        single-mouse/cursor input model.





        On 12/02/2012 02:52 AM, Sam Lantinga wrote:


            In general, I think you only want to handle the mouse
    events,
            unless you're
            doing something that's specifically touch sensitive, e.g.
            handling gestures.
              The intent is that you can assume that any touch
    input will
            also generate
            simulated mouse events if no mouse is present, so any
            non-touch-specific UI
            elements will work consistently on platforms with only
    mice as
            well as platforms
            with only touch input.

            If you have a UI element that works better with touch
    input
            for some reason,
            then as soon as you get touch input events you should
    reset
            your state and start
            ignoring mouse input.

            Looking at the event sequence it may make sense to
    send the
            touch events first
            so you know the mouse events are coming. e.g.

            FINGERDOWN
            MOUSEMOTION
            MOUSEBUTTONDOWN
            FINGERMOTION ,MOUSEMOTION,... dozens of these pairs.
            FINGERUP
            MOUSEBUTTONUP

            Cheers!

            On Sat, Dec 1, 2012 at 8:47 PM, John <john at puckerupgames.com <mailto:john at puckerupgames.com> <mailto:john at puckerupgames.com <mailto:john at puckerupgames.com>> <mailto:john at puckerupgames.com <mailto:john at puckerupgames.com> <mailto:john at puckerupgames.com <mailto:john at puckerupgames.com>>>> wrote:

                Yes, sort of.  It's not important to me whether
    the events
            were truly
                triggered by such-and-such device, although I can
    see why
            an app might need
                that. I'd like to know how a "well behaved" app
    event loop
            should interpret
                the new SDL events. Knowing that, I can revise my
    apps to
            follow suit.

                Perhaps a real example would make more sense: A game
            displays a button
                graphic. The player can "press" the on-screen
    button with
            a mouse down
                event. They may also press the on-screen button with a
            finger event. The app
                handles both events, and it handles the "up" events as
            well in order to
                alter the button appearance. Just your typical
            "onmousedown/onmouseup" sort
                of stuff. The code compiles nicely on all
    platforms that
            SDL supports. Now,
                with the mouse emulation patch applied, on
    Android, when
            the user touches
                the screen, the app recieves a flurry of mouse
    events AND
            touch events. The
                mousemotion is even weirder, because the mouse
    emulation
            patch generates
                very sudden, fast motion when there is no motion
    at all.
            On finger-down, SDL
                moves the "fake" mouse location from it's
    previously fake
            location to the
                new finger location by generating a mouse motion
    event.
            Kinda like the old
                WarpMouse call.

                Here's the event sequence on Android before the patch,
            when the user touches
                the screen then releases:

                FINGERDOWN
                FINGERMOTION
                FINGERMOTION... dozens of these.
                FINGERUP

                Here's the event sequence after the emulation patch:

                MOUSEMOTION
                MOUSEBUTTONDOWN
                FINGERDOWN
                MOUSEMOTION,FINGERMOTION,.. dozens of these pairs.
                MOUSEBUTTONUP
                FINGERUP





                On 12/01/2012 10:08 PM, Sik the hedgehog wrote:

                    So you want to distinguish between cursor events
            caused by the mouse
                    and cursor events caused by touch, if I'm
            understanding right?
                    (honestly it should be called cursor, not mouse)

                    2012/12/1 John <john at puckerupgames.com
    <mailto:john at puckerupgames.com>
            <mailto:john at puckerupgames.com
    <mailto:john at puckerupgames.com>>
    <mailto:john at puckerupgames.com <mailto:john at puckerupgames.com>

            <mailto:john at puckerupgames.com
    <mailto:john at puckerupgames.com>>>>:


                        How will the app event handler know whether to
            ignore mouse events?

                        I think the issue is that now SDL is always in
            this emulation mode. It
                        generates fake mouse events whenever it
    sees touch
            events, then delivers
                        BOTH events to the app. From the
    perspective of an
            app's event loop,
                        sometimes SDL_MouseEvent is really a mouse
    event,
            and sometimes it is a
                        duplicate of a touch event or a finger event.

                        I guess this is really a question of what
    an app
            event loop should
                        look like
                        now. Say an app's event handler resembles
    this code,

                            case SDL_MOUSEBUTTONDOWN:
    handle_mousedown();
            break;
                            case SDL_TOUCHBUTTONDOWN:
            handle_touchbuttondown(); break;
                            case SDL_FINGERDOWN:
     handle_fingerdown(); break;
                            case SDL_MOUSEMOTION:
    handle_mousemotion(); break;
                            case SDL_FINGERMOTION:
     handle_fingermotion();
            break;
                            case SDL_MOUSEWHEEL:
     handle_mousewheel(); break;
                            ...etc.

                        How would you recommend app developers revise
            their event handlers
                        to work
                        after the mouse emulation patch?




                        On 12/01/2012 05:17 PM, Sam Lantinga wrote:


                            This is a required feature for games
    that use
            gesture support as
                            well as
                            mouse
                            interaction.  If you prefer to use
    only touch
            events, can you
                            ignore the
                            mouse
                            events?

                            On Thu, Nov 29, 2012 at 3:31 PM, John <john at puckerupgames.com <mailto:john at puckerupgames.com> <mailto:john at puckerupgames.com <mailto:john at puckerupgames.com>> <mailto:john at puckerupgames.com <mailto:john at puckerupgames.com> <mailto:john at puckerupgames.com <mailto:john at puckerupgames.com>>> <mailto:john at puckerupgames.com <mailto:john at puckerupgames.com> <mailto:john at puckerupgames.com <mailto:john at puckerupgames.com>> <mailto:john at puckerupgames.com <mailto:john at puckerupgames.com> <mailto:john at puckerupgames.com <mailto:john at puckerupgames.com>>>__>> wrote:

                                  Hi,

                                  The patch in the SDL trunk (listed
            below) breaks apps that
                            correctly
                            handle
                                  mouse and touch events. Apps will
            receive mouse events AND
                            touch
                            events.
                                  Also, the precision of the mouse
    events
            will be incredibly
                            lossy due
                            to
                                  integer truncation when compared
    with
            the touch events,
                            which have
                            double
                                  precision.

                                  Recommend removing this patch
    altogether.

                                  The patch in question is
    http://hg.libsdl.org/SDL/raw-____rev/17ef8a7cab55
                           
    <http://hg.libsdl.org/SDL/raw-__rev/17ef8a7cab55>
                                       
     <http://hg.libsdl.org/SDL/raw-__rev/17ef8a7cab55
                           
    <http://hg.libsdl.org/SDL/raw-rev/17ef8a7cab55>>
                                  in file
            "src/video/android/SDL_____androidtouch.c"


                                  -John


     ___________________________________________________

                                  SDL mailing list
    SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
    <mailto:SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>>
            <mailto:SDL at lists.libsdl.org
    <mailto:SDL at lists.libsdl.org> <mailto:SDL at lists.libsdl.org
    <mailto:SDL at lists.libsdl.org>>>
                            <mailto:SDL at lists.libsdl.org
    <mailto:SDL at lists.libsdl.org>
            <mailto:SDL at lists.libsdl.org
    <mailto:SDL at lists.libsdl.org>> <mailto:SDL at lists.libsdl.org
    <mailto:SDL at lists.libsdl.org>
            <mailto:SDL at lists.libsdl.org
    <mailto: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 <mailto:SDL at lists.libsdl.org>
    <mailto:SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>>
            <mailto:SDL at lists.libsdl.org
    <mailto:SDL at lists.libsdl.org> <mailto:SDL at lists.libsdl.org
    <mailto: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 <mailto:SDL at lists.libsdl.org>
    <mailto:SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>>
            <mailto:SDL at lists.libsdl.org
    <mailto:SDL at lists.libsdl.org> <mailto:SDL at lists.libsdl.org
    <mailto: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 <mailto:SDL at lists.libsdl.org>
    <mailto:SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>>
            <mailto:SDL at lists.libsdl.org
    <mailto:SDL at lists.libsdl.org> <mailto:SDL at lists.libsdl.org
    <mailto: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 <mailto:SDL at lists.libsdl.org>
    <mailto:SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>>
            <mailto:SDL at lists.libsdl.org
    <mailto:SDL at lists.libsdl.org> <mailto:SDL at lists.libsdl.org
    <mailto: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 <mailto:SDL at lists.libsdl.org>
    <mailto:SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>>

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

        _______________________________________________
        SDL mailing list
    SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
    <mailto:SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>>

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




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


-- 
*Pallav Nawani*
*Game Designer/CEO*
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming

_______________________________________________
SDL mailing list
SDL at lists.libsdl.org <mailto: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

–
Pallav Nawani
Game Designer/CEO
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming

Another_Idea · January 9, 2013, 4:13pm

It seems to me that the simplest solution would be:

By default, map touch events to mouse events, and provide no touch events
via the API. This allows SDL to abstract the hardware details away from
touch-ignorant SDL applications.
If an app “enables” touch events (during initialization), SDL should return
touch events and should not map them to mouse events. This allows touch-aware
SDL applications to support both touch and mouse simultaneously and distinctly,
without any duplication.

Or, alternatively:

2b) A possible variation of #2: map single-finger motion touches & motion
events to mouse events (tracking the first finger down and ignoring others for
the purpose of mouse-mapping), and return everything else as touch events.
This would allow pointing-device behavior to be handled more easily, while
restricting “touch events” to the truly interesting cases. But it’s
conceptually a little icky.

However, if people really want to have both generated mouse events and
corresponding touch events at the same time, you’d need some way of
correlating real touch events to their generated mouse events, as others have
mentioned. It’s just not clear to me why somebody would want this, given the
above options.

The simplest and most flexible approach for this would be a simple event
serial number along with a field indicating whether an event was generated
from some other event. When the field is zero, the event is original. When
nonzero, the field contains the type of the event from which the current event
was generated. Then, by looking for an event of that type with the same
serial number, you could find the original event.

Sik_the_hedgehog · January 15, 2013, 10:33pm

I imagine the biggest problem with #2a is SDL_INIT_EVERYTHING. That’d
enable touch by default. If programs didn’t use that then it’d be
probably the ideal solution. (I personally enable things one by one,
so I can catch when something in particular fails)

2013/1/9, Another Idea :> It seems to me that the simplest solution would be:

By default, map touch events to mouse events, and provide no touch
events
via the API. This allows SDL to abstract the hardware details away from
touch-ignorant SDL applications.

If an app “enables” touch events (during initialization), SDL should
return
touch events and should not map them to mouse events. This allows
touch-aware
SDL applications to support both touch and mouse simultaneously and
distinctly,
without any duplication.

Or, alternatively:

2b) A possible variation of #2: map single-finger motion touches & motion
events to mouse events (tracking the first finger down and ignoring others
for
the purpose of mouse-mapping), and return everything else as touch events.
This would allow pointing-device behavior to be handled more easily, while
restricting “touch events” to the truly interesting cases. But it’s
conceptually a little icky.

However, if people really want to have both generated mouse events and
corresponding touch events at the same time, you’d need some way of
correlating real touch events to their generated mouse events, as others
have
mentioned. It’s just not clear to me why somebody would want this, given
the
above options.

The simplest and most flexible approach for this would be a simple event
serial number along with a field indicating whether an event was generated
from some other event. When the field is zero, the event is original.
When
nonzero, the field contains the type of the event from which the current
event
was generated. Then, by looking for an event of that type with the same
serial number, you could find the original event.

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

Gabriele_Greco · January 16, 2013, 5:00pm

By default, map touch events to mouse events, and provide no touch
events

If an app “enables” touch events (during initialization), SDL should
return
2b) A possible variation of #2: map single-finger motion touches & motion

IMHO both approaches are wrong.

The correct one is the actual one (mouse != touch), with the addition of
SDL_Hints to force a sort of OPTIONAL mirroring of touch -> mouse.

Devices with both mouses and touch screen will become more and more common.

For instance, it’s a recent news that Intel will enforce the use of touch
screen monitors with his 2013 line of low power processors…–
Bye,
Gabry