SetWindowGrab (OSX) does wrong operation

SDL Development
1

I have just used SDL_SetWindowGrab in my editor to implement moving the
pane dividers by grabbing the divider with the mouse. (left button down
and hold to grab and move).

The mouse shows a nice NSArrow cursor when over the divider area.

Without setting the grab, control over the divider is lost when the mouse
cursor is moved off the screen. So even if you release the mouse button
my program doesn’t know about it and if the mouse is moved back over
the screen the divider move operation continues (yes I could check the
button state, but it doesn’t make sense).

Of course grabbing is supposed to fix that, and the logic works fine,
although the mouse cursor switches to the wrong shape (I can fix that,
its a bug in my program)

Here’s the problem: what SDL seems to do is, if you try to move the mouse
off the window it warps it back. So the mouse, held off window with button
down, flickers and flashes. Its totally ugly and horrible (my editor is currently
very slow rendering).

This is not what a grab should do. It isn’t supposed to put the mouse in jail.
The mouse should be allowed to go off window, it just remains associated
with the window so button clicks and motion are registered.

If I then want to force the mouse inside the window I can warp it there
myself. in fact, I’d be warping it into the divider not merely the window.
And probably removing all horizontal motion if I did (so it appears glued
to the divider at the point where the button was pressed).

MacVim gets its wrong too, although it has a different bug: it correctly allows
the mouse to move where it wants, and continues to track the position and
button state (but it gets the cursor shape wrong).

So: IMHO this is a bug in SDL. Anyone have different opinion on what should
happen? Is there a way to fix this on OSX (and any other platform with the same
problem)?

I think I can fix this by hiding the mouse cursor entirely, then it won’t flicker
and I can render something onto the divider at the grab point. However it
isn’t clear what coordinates will be returned.

For many programs (including MacVim) the panning speed is determined
by how far off the window you move. This is actually a pain if the window
bottom is close to the screen bottom. However the point is to implement
this, again:

(a) input from the mouse must be grabbed
(b) the mouse must NOT be put in jail–
john skaller
@john_skaller
http://felix-lang.org

2

The wiki page (http://wiki.libsdl.org/moin.fcg/SDL_SetWindowGrab) says this:
“When input is grabbed the mouse is confined to the window.”

This is what it does on all platforms, both in SDL 2.0 and 1.2. It’s not a bug, it’s
what that function is designed to do.

The way it was implemented in OS X (at least before J?rgen’s recent update to
the code) left something to be desired since it was possible for mouse input
to escape the program in some cases, but I believe it’s better now when you
compile SDL with SDL_MAC_NO_SANDBOX defined.On 2013-08-11, at 7:20 PM, john skaller wrote:

I have just used SDL_SetWindowGrab in my editor to implement moving the
pane dividers by grabbing the divider with the mouse. (left button down
and hold to grab and move).

The mouse shows a nice NSArrow cursor when over the divider area.

Without setting the grab, control over the divider is lost when the mouse
cursor is moved off the screen. So even if you release the mouse button
my program doesn’t know about it and if the mouse is moved back over
the screen the divider move operation continues (yes I could check the
button state, but it doesn’t make sense).

Of course grabbing is supposed to fix that, and the logic works fine,
although the mouse cursor switches to the wrong shape (I can fix that,
its a bug in my program)

Here’s the problem: what SDL seems to do is, if you try to move the mouse
off the window it warps it back. So the mouse, held off window with button
down, flickers and flashes. Its totally ugly and horrible (my editor is currently
very slow rendering).

This is not what a grab should do. It isn’t supposed to put the mouse in jail.
The mouse should be allowed to go off window, it just remains associated
with the window so button clicks and motion are registered.

If I then want to force the mouse inside the window I can warp it there
myself. in fact, I’d be warping it into the divider not merely the window.
And probably removing all horizontal motion if I did (so it appears glued
to the divider at the point where the button was pressed).

MacVim gets its wrong too, although it has a different bug: it correctly allows
the mouse to move where it wants, and continues to track the position and
button state (but it gets the cursor shape wrong).

So: IMHO this is a bug in SDL. Anyone have different opinion on what should
happen? Is there a way to fix this on OSX (and any other platform with the same
problem)?

I think I can fix this by hiding the mouse cursor entirely, then it won’t flicker
and I can render something onto the divider at the grab point. However it
isn’t clear what coordinates will be returned.

For many programs (including MacVim) the panning speed is determined
by how far off the window you move. This is actually a pain if the window
bottom is close to the screen bottom. However the point is to implement
this, again:

(a) input from the mouse must be grabbed
(b) the mouse must NOT be put in jail

–
john skaller
skaller at users.sourceforge.net
http://felix-lang.org

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

3

The wiki page (http://wiki.libsdl.org/moin.fcg/SDL_SetWindowGrab) says this:
“When input is grabbed the mouse is confined to the window.”

This is what it does on all platforms, both in SDL 2.0 and 1.2. It’s not a bug, it’s
what that function is designed to do.

In that case another function is required which does not confine the
mouse to the window.

The SDL behaviour is unconventional. for example:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms645601(v=vs.85).aspx#_win32_Mouse_Capture

Mouse Capture

The system typically posts a mouse message to the window that contains the cursor hot spot when a mouse event occurs. An application can change this behavior by using the SetCapture function to route mouse messages to a specific window. The window receives all mouse messages until the application calls the ReleaseCapture function or specifies another capture window, or until the user clicks a window created by another thread.

Don’t have a reference, but I’m pretty sure Linux does the same.On 12/08/2013, at 3:36 PM, Alex Szpakowski wrote:

–
john skaller
@john_skaller
http://felix-lang.org