This one is ugly. If you are NOT in full screen, you don’t get right mouse events. As far as I can tell from googling, the bug in SDL is SDL detects if there are windows to consume the mouse events and lets them handle this. This fails for right mouse events, because (if what I read is correct) they are getting caught by the contextual menu routines.
This code is where the problem is:================
void
Cocoa_HandleMouseEvent(_THIS, NSEvent *event)
{
int i;
NSPoint point = { 0, 0 };
SDL_Window *window;
SDL_Window *focus = SDL_GetMouseFocus();
/* See if there are any fullscreen windows that might handle this event */
window = NULL;
for (i = 0; i < _this->num_displays; ++i) {
SDL_VideoDisplay *display = &_this->displays[i];
SDL_Window *candidate = display->fullscreen_window;
if (candidate) {
SDL_Rect bounds;
Cocoa_GetDisplayBounds(_this, display, &bounds);
point = [NSEvent mouseLocation];
point.x = point.x - bounds.x;
point.y = CGDisplayPixelsHigh(kCGDirectMainDisplay) - point.y - bounds.y;
if ((point.x >= 0 && point.x < candidate->w) &&
(point.y >= 0 && point.y < candidate->h)) {
/* This is it! */
window = candidate;
break;
} else if (candidate == focus) {
SDL_SetMouseFocus(NULL);
}
}
}
if (!window) {
return;
}
=================
I have NO idea what the above code is doing or why (aside from the comment), but if it activates, it skips out on the remaining code that directly sends the mouse events on to the SDL layer. If you erase all this code and instead just do this:
=================
window=SDL_GetMouseFocus();
if (!window) {
return;
}
=================
You begin getting right clicks in non-full screen contexts (and still seems to work in full screen.)
AGAIN, I no NOTHING about obj-c, so this is my quick and dirty learning curve and figuring out what’s going on. I could be completely wrong, and I have NO idea what removing that code will break. Can somebody with a bit more experience comment on this?
Hi Brian,On Sun, Nov 21, 2010 at 7:53 PM, Brian Barnes wrote:
This one is ugly. ?If you are NOT in full screen, you don’t get right mouse
events. ?As far as I can tell from googling, the bug in SDL is SDL detects
if there are windows to consume the mouse events and lets them handle this.
?This fails for right mouse events, because (if what I read is correct) they
are getting caught by the contextual menu routines.
This code is where the problem is:
I have NO idea what the above code is doing or why (aside from the comment),
but if it activates, it skips out on the remaining code that directly sends
the mouse events on to the SDL layer. ?If you erase all this code and
instead just do this:
You begin getting right clicks in non-full screen contexts (and still seems
to work in full screen.)
AGAIN, I no NOTHING about obj-c, so this is my quick and dirty learning
curve and figuring out what’s going on. ?I could be completely wrong, and I
have NO idea what removing that code will break. ?Can somebody with a bit
more experience comment on this?
I believe the same issue has been discussed a while ago [1].
I wrote a patch (attached here) to fix this, apparently it isn’t included.
I’m not sure if the patch still applies. Good luck.
I believe the same issue has been discussed a while ago [1].
I wrote a patch (attached here) to fix this, apparently it isn’t included.
I’m not sure if the patch still applies. Good luck.
It looks like parts of that patch are in there – but I think we might be looking at two bugs (one only under certain circumstances), a rollback, or just an incomplete patching job. I think what might be the real solution to this is remove mouse events from the window level and always capture them at the app level; this way they never get eaten by anything special at the window level. That would also take removing them at the window level (relatively self contained) and always catching them at the app level (which the code already exists.) It’d probably simplify the code a bit.
This is something the OS X guy – and who is that?? – would have to decide on to do.
There’s a lot that’s just broken, but until somebody with some power and better understanding steps up, nothing is going to get done, and 1.3 is going to be very broken. I’m literally just experimenting with the code to fix things, I have no idea if these fixes are proper or warranted.
So far:
Right mouse button doesn’t work
All the “grabbed input” methods don’t work like the docs say
Full screen modes re-arrange the desktop
XCode project doesn’t compile without changes to NSTouch interface
Sorry, I’ve been preoccupied with other things and haven’t had time to
seriously look at the 1.3 backend. Sam wrote most of the new backend I
believe. Awhile back, I was rambling that I would like to see the
backend rewritten so that instead of going through NSWindow for all
the events, I would like to move away from that and target several
different subcomponents. At the lowest level, I would like to see
implemented a bunch of things at the CALayer level which would give us
interesting possibilities of putting SDL rendering inside layers which
can be transformed around inside other views (think Cover Flow). It
also gives us some ability to unify the iOS and Mac code base.
Then there would be a NSView container view wrapping of the layer for
Mac. NSView also potentially has access to implementing mouse events
like NSWindow. I haven’t thought seriously about what the best way to
implement the mouse system is, but I think NSWindow might be my least
favorite. So your proposal (superficially) to me sounds like a good
one.
But since I’m currently not writing anything on this, I’m merely a
backseat driver.
I believe the same issue has been discussed a while ago [1].
I wrote a patch (attached here) to fix this, apparently it isn’t included.
I’m not sure if the patch still applies. Good luck.
It looks like parts of that patch are in there – but I think we might be
looking at two bugs (one only under certain circumstances), a rollback, or
just an incomplete patching job. I think what might be the real solution
to this is remove mouse events from the window level and always capture them
at the app level; this way they never get eaten by anything special at the
window level. That would also take removing them at the window level
(relatively self contained) and always catching them at the app level (which
the code already exists.) It’d probably simplify the code a bit.
This is something the OS X guy – and who is that?? – would have to decide
on to do.
There’s a lot that’s just broken, but until somebody with some power and
better understanding steps up, nothing is going to get done, and 1.3 is
going to be very broken. I’m literally just experimenting with the code to
fix things, I have no idea if these fixes are proper or warranted.
So far:
Right mouse button doesn’t work
All the “grabbed input” methods don’t work like the docs say
Full screen modes re-arrange the desktop
XCode project doesn’t compile without changes to NSTouch interface
Sorry, I’ve been preoccupied with other things and haven’t had time to
seriously look at the 1.3 backend. Sam wrote most of the new backend I
believe. Awhile back, I was rambling that I would like to see the
backend rewritten so that instead of going through NSWindow for all
the events, I would like to move away from that and target several
different subcomponents. At the lowest level, I would like to see
implemented a bunch of things at the CALayer level which would give us
interesting possibilities of putting SDL rendering inside layers which
can be transformed around inside other views (think Cover Flow). It
also gives us some ability to unify the iOS and Mac code base.
Then there would be a NSView container view wrapping of the layer for
Mac. NSView also potentially has access to implementing mouse events
like NSWindow. I haven’t thought seriously about what the best way to
implement the mouse system is, but I think NSWindow might be my least
favorite. So your proposal (superficially) to me sounds like a good
one.
But since I’m currently not writing anything on this, I’m merely a
backseat driver.
Hi Eric!
I’m guessing Sam didn’t do it as he said he doesn’t know cocoa well (that might have been somebody else that said that, sorry if I misunderstood.) I don’t either, I only know it now because I was going through the SDL code, but I’m no expert, which is why I just proposal instead of patch
I put my code back to SDL 1.2 (through a bunch of ifdefs) because I need to get back to work, but anybody that wants what I came up with or put it together better, or have me test (which I can just switch back), please get ahold of me!
Just to rehash, my things were:
Separate 10.4 and 10.6 into two separate targets (and ifdef out the touch package in SDL_cocoawindow)
Right mouse failures (the fix above)
Relative mouse mode broken (my proposal was to implement a SetNativeCursorPosWindow in SDL_VideoDevice, implement in the glue code, and do the re-centering in SDL_SendMouseMotion – the only problem is handling the events that the recenter generates.)
Going out of full screen can move the windows around in OS X
See ya!On Sun, Nov 21, 2010 at 3:05 PM, Jjgod Jiang wrote:
Hi Brian,
On Sun, Nov 21, 2010 at 7:53 PM, Brian Barnes wrote:
This one is ugly. ?If you are NOT in full screen, you don’t get right mouse
events. ?As far as I can tell from googling, the bug in SDL is SDL detects
if there are windows to consume the mouse events and lets them handle this.
?This fails for right mouse events, because (if what I read is correct) they
are getting caught by the contextual menu routines.
This code is where the problem is:
I have NO idea what the above code is doing or why (aside from the comment),
but if it activates, it skips out on the remaining code that directly sends
the mouse events on to the SDL layer. ?If you erase all this code and
instead just do this:
You begin getting right clicks in non-full screen contexts (and still seems
to work in full screen.)
AGAIN, I no NOTHING about obj-c, so this is my quick and dirty learning
curve and figuring out what’s going on. ?I could be completely wrong, and I
have NO idea what removing that code will break. ?Can somebody with a bit
more experience comment on this?
I believe the same issue has been discussed a while ago [1].
I wrote a patch (attached here) to fix this, apparently it isn’t included.
I’m not sure if the patch still applies. Good luck.
The right click support should be fixed with the latest changes.
I’m working on compiling it on Mac OS 10.5 now, and the relative mouse
motion is on my TODO list.
I’d love for anyone to tackle the other things on the list…
See ya!On Wed, Nov 24, 2010 at 5:15 PM, Brian Barnes wrote:
Eric Wing wrote:
Sorry, I’ve been preoccupied with other things and haven’t had time to
seriously look at the 1.3 backend. Sam wrote most of the new backend I
believe. Awhile back, I was rambling that I would like to see the
backend rewritten so that instead of going through NSWindow for all
the events, I would like to move away from that and target several
different subcomponents. At the lowest level, I would like to see
implemented a bunch of things at the CALayer level which would give us
interesting possibilities of putting SDL rendering inside layers which
can be transformed around inside other views (think Cover Flow). It
also gives us some ability to unify the iOS and Mac code base.
Then there would be a NSView container view wrapping of the layer for
Mac. NSView also potentially has access to implementing mouse events
like NSWindow. I haven’t thought seriously about what the best way to
implement the mouse system is, but I think NSWindow might be my least
favorite. So your proposal (superficially) to me sounds like a good
one.
But since I’m currently not writing anything on this, I’m merely a
backseat driver.
Hi Eric!
I’m guessing Sam didn’t do it as he said he doesn’t know cocoa well (that might have been somebody else that said that, sorry if I misunderstood.) ?I don’t either, I only know it now because I was going through the SDL code, but I’m no expert, which is why I just proposal instead of patch
I put my code back to SDL 1.2 (through a bunch of ifdefs) because I need to get back to work, but anybody that wants what I came up with or put it together better, or have me test (which I can just switch back), please get ahold of me!
Just to rehash, my things were:
Separate 10.4 and 10.6 into two separate targets (and ifdef out the touch package in SDL_cocoawindow)
Right mouse failures (the fix above)
Relative mouse mode broken (my proposal was to implement a SetNativeCursorPosWindow in SDL_VideoDevice, implement in the glue code, and do the re-centering in SDL_SendMouseMotion – the only problem is handling the events that the recenter generates.)
Going out of full screen can move the windows around in OS X
The right click support should be fixed with the latest changes.
I’m working on compiling it on Mac OS 10.5 now, and the relative mouse
motion is on my TODO list.
I’d love for anyone to tackle the other things on the list…
See ya!
My suggestion is you make two targets; one a 10.6 (and probably intel
only) target, and a 10.4 (lots of people still have this and lots of
developers want to support it) ppc/intel 32 bit target.
The only thing that is a problem (you can check my older email) is the
NSTouch interface. It didn’t exist until 10.6. If you dupe the current
target, set the SDK to 10.4, and then surround the NSTouch code with
ifdefs, it works great.
Drop a note on the list when you have relative working. dim3 has all
the 1.2/1.3 code behind defines so I can switch in and out and test both
the OS X and win32 version.
Great, I’ll definitely let you know, and I’d appreciate bug reports
when everything is stable.
Thanks!On Thu, Dec 2, 2010 at 4:52 AM, Brian Barnes wrote:
Sam Lantinga wrote:
The right click support should be fixed with the latest changes.
I’m working on compiling it on Mac OS 10.5 now, and the relative mouse
motion is on my TODO list.
I’d love for anyone to tackle the other things on the list…
See ya!
My suggestion is you make two targets; one a 10.6 (and probably intel only)
target, and a 10.4 (lots of people still have this and lots of developers
want to support it) ppc/intel 32 bit target.
The only thing that is a problem (you can check my older email) is the
NSTouch interface. ?It didn’t exist until 10.6. ?If you dupe the current
target, set the SDK to 10.4, and then surround the NSTouch code with ifdefs,
it works great.
Drop a note on the list when you have relative working. ?dim3 has all the
1.2/1.3 code behind defines so I can switch in and out and test both the OS
X and win32 version.
