Hello,
just to let you know I’ve posted two bug reports at SDL bug tracker and since I’m not sure if it’s alive, I’m sending the information also here:
http://bugzilla.libsdl.org/show_bug.cgi?id=998
http://bugzilla.libsdl.org/show_bug.cgi?id=999
regards,
Pavel Kanzelsberger
Hi Pavel,On Fri, May 7, 2010 at 5:14 AM, Pavel Kanzelsberger wrote:
just to let you know I’ve posted two bug reports at SDL bug tracker and since I’m not sure if it’s alive, I’m sending the information also here:
- SDL 1.3 Cocoa, right mouse button doesn’t work at all
I am investigating this issue, basically the event handling code in
Cocoa is a bit confusing, the right mouse button event is not directly
picked from event dispatching process but handled in the responder in
SDL_cocoawindow.m. I guess its easier to find out window id. But
NSResponder cannot receive rightMouse/otherMouse events if NSView
already intercept it, that’s why you cannot receive it from SDL.
I think the solution will be either: pick up the mouse events directly
from event queue, or override NSView to get the rightMouse… events.
I can provide a patch if Sam or Ryan decided which way is better.
Which works better when interacting with foreign windows or integrated
into a Cocoa UI?On Thu, May 6, 2010 at 6:54 PM, Jjgod Jiang wrote:
Hi Pavel,
On Fri, May 7, 2010 at 5:14 AM, Pavel Kanzelsberger wrote:
just to let you know I’ve posted two bug reports at SDL bug tracker and since I’m not sure if it’s alive, I’m sending the information also here:
- SDL 1.3 Cocoa, right mouse button doesn’t work at all
I am investigating this issue, basically the event handling code in
Cocoa is a bit confusing, the right mouse button event is not directly
picked from event dispatching process but handled in the responder in
SDL_cocoawindow.m. I guess its easier to find out window id. But
NSResponder cannot receive rightMouse/otherMouse events if NSView
already intercept it, that’s why you cannot receive it from SDL.I think the solution will be either: pick up the mouse events directly
from event queue, or override NSView to get the rightMouse… events.
I can provide a patch if Sam or Ryan decided which way is better.
- Jiang
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
Hello,
I’m not sure how is it right now, but it’s better if Windows are Cocoa and not something else (foreign, Carbon, whatever), so you can access the NSWindow class, and also I think SDL is using a CGContext from NSView right? For example I’m reusing the very same context for rendering texts using CoreText and so on…
PavelOn 8.5.2010, at 10:35, Sam Lantinga wrote:
Which works better when interacting with foreign windows or integrated
into a Cocoa UI?On Thu, May 6, 2010 at 6:54 PM, Jjgod Jiang wrote:
Hi Pavel,
On Fri, May 7, 2010 at 5:14 AM, Pavel Kanzelsberger <@Pavel_Kanzelsberger> wrote:
just to let you know I’ve posted two bug reports at SDL bug tracker and since I’m not sure if it’s alive, I’m sending the information also here:
- SDL 1.3 Cocoa, right mouse button doesn’t work at all
I am investigating this issue, basically the event handling code in
Cocoa is a bit confusing, the right mouse button event is not directly
picked from event dispatching process but handled in the responder in
SDL_cocoawindow.m. I guess its easier to find out window id. But
NSResponder cannot receive rightMouse/otherMouse events if NSView
already intercept it, that’s why you cannot receive it from SDL.I think the solution will be either: pick up the mouse events directly
from event queue, or override NSView to get the rightMouse… events.
I can provide a patch if Sam or Ryan decided which way is better.
- Jiang
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Which works better when interacting with foreign windows or integrated
into a Cocoa UI?Hi Pavel,
just to let you know I’ve posted two bug reports at SDL bug tracker and
since I’m not sure if it’s alive, I’m sending the information also here:
- SDL 1.3 Cocoa, right mouse button doesn’t work at all
I am investigating this issue, basically the event handling code in
Cocoa is a bit confusing, the right mouse button event is not directly
picked from event dispatching process but handled in the responder in
SDL_cocoawindow.m. I guess its easier to find out window id. But
NSResponder cannot receive rightMouse/otherMouse events if NSView
already intercept it, that’s why you cannot receive it from SDL.I think the solution will be either: pick up the mouse events directly
from event queue, or override NSView to get the rightMouse… events.
I can provide a patch if Sam or Ryan decided which way is better.
- Jiang
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
One (somewhat academic) thing I would like to see the return of is the
ability to have a self-contained NSView which contains all the SDL
stuff. (We lost this when we purged all the deprecated stuff.) Then
you could create native Cocoa UIs with multiple views in a single
window, one of which could be an SDL view. (In theory, we might even
be able to extend the idea to multiple SDL views since SDL has
multiple window support in 1.3.) So I think event handling at the view
level might make more sense for this. (Though if anybody believes
otherwise, I would love to hear the explanation.)
On this topic, I would like to extend the idea one step further and
even suggest we consider breaking down the SDL rendering surface parts
into a Core Animation layer (CALayer) instead of an NSView. Then we
encapsulate the SDL (visual) CALayer in a custom NSView which contains
the event handling parts of SDL. This would allow the SDL visual parts
to be added and directly manipulated inside with other NSViews. For
example, think of a iTunes/Cover Flow like example. You are browsing
through a visual list of album art things. Well, one of those Album
art things could be an SDL layer which is rendering a game or
something.
Also, an advantage to this design is there may be a little more
consistency between the Mac and iPhone implementations since CALayer
can be used as a fundmental drawing surface on both OS’s.
-EricOn 5/8/10, Sam Lantinga wrote:
On Thu, May 6, 2010 at 6:54 PM, Jjgod Jiang wrote:
On Fri, May 7, 2010 at 5:14 AM, Pavel Kanzelsberger wrote:
Hi Pavel,On Sat, May 8, 2010 at 4:53 PM, Pavel Kanzelsberger wrote:
I’m not sure how is it right now, but it’s better if Windows are Cocoa and not something else (foreign, Carbon, whatever), so you can access the NSWindow class, and also I think SDL is using a CGContext from NSView right? For example I’m reusing the very same context for rendering texts using CoreText and so on…
As I understand SDL does not use the CGContext from NSView directly,
it will create a NSWindow for rendering, and NSWindow will create a
NSView as its default content view. Then SDL will create a
NSOpenGLContext and set its view as that content view.
The right mouse event handling is different in Cocoa because it is
expected to show the context menu. So NSView will intercept it.
See attached patch for a simple fix.
Hi,On Sat, May 8, 2010 at 4:35 PM, Sam Lantinga wrote:
Which works better when interacting with foreign windows or integrated
into a Cocoa UI?
That’s what I’d like to ask too. Pavel seemed to have a perfect application
for this so his usage pattern should be valuable. The fix I just sent will
leave everything in foreign windows as is but make the windows created by
SDL correctly emit right mouse down events. I hope that’s enough for Pavel’s
need. However, if he wants to integrate a context menu (NSMenu in Cocoa)
with the window created by SDL, my solution will not be very handy to use.
In that case, we may want to allow the application to pass a custom NSView
as the content view of a SDL window.
Hi Eric,On Sat, May 8, 2010 at 5:54 PM, Eric Wing wrote:
One (somewhat academic) thing I would like to see the return of is the
ability to have a self-contained NSView which contains all the SDL
stuff. (We lost this when we purged all the deprecated stuff.) Then
you could create native Cocoa UIs with multiple views in a single
window, one of which could be an SDL view. (In theory, we might even
be able to extend the idea to multiple SDL views since SDL has
multiple window support in 1.3.) So I think event handling at the view
level might make more sense for this. (Though if anybody believes
otherwise, I would love to hear the explanation.)On this topic, I would like to extend the idea one step further and
even suggest we consider breaking down the SDL rendering surface parts
into a Core Animation layer (CALayer) instead of an NSView. Then we
encapsulate the SDL (visual) CALayer in a custom NSView which contains
the event handling parts of SDL. This would allow the SDL visual parts
to be added and directly manipulated inside with other NSViews. For
example, think of a iTunes/Cover Flow like example. You are browsing
through a visual list of album art things. Well, one of those Album
art things could be an SDL layer which is rendering a game or
something.Also, an advantage to this design is there may be a little more
consistency between the Mac and iPhone implementations since CALayer
can be used as a fundmental drawing surface on both OS’s.
I think that’s a very interesting suggestion and certainly will be
nice to have. The question is how we can fit it into current SDL APIs
and if not, in which way we should change it.
Yes, I’m open to discussion on this. I don’t know Cocoa development
well enough to have my own opinion…On Sat, May 8, 2010 at 10:46 PM, Jjgod Jiang wrote:
Hi Eric,
On Sat, May 8, 2010 at 5:54 PM, Eric Wing wrote:
One (somewhat academic) thing I would like to see the return of is the
ability to have a self-contained NSView which contains all the SDL
stuff. (We lost this when we purged all the deprecated stuff.) Then
you could create native Cocoa UIs with multiple views in a single
window, one of which could be an SDL view. (In theory, we might even
be able to extend the idea to multiple SDL views since SDL has
multiple window support in 1.3.) So I think event handling at the view
level might make more sense for this. (Though if anybody believes
otherwise, I would love to hear the explanation.)On this topic, I would like to extend the idea one step further and
even suggest we consider breaking down the SDL rendering surface parts
into a Core Animation layer (CALayer) instead of an NSView. Then we
encapsulate the SDL (visual) CALayer in a custom NSView which contains
the event handling parts of SDL. This would allow the SDL visual parts
to be added and directly manipulated inside with other NSViews. For
example, think of a iTunes/Cover Flow like example. You are browsing
through a visual list of album art things. Well, one of those Album
art things could be an SDL layer which is rendering a game or
something.Also, an advantage to this design is there may be a little more
consistency between the Mac and iPhone implementations since CALayer
can be used as a fundmental drawing surface on both OS’s.I think that’s a very interesting suggestion and certainly will be
nice to have. The question is how we can fit it into current SDL APIs
and if not, in which way we should change it.
- Jiang
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
Hello Jiang,
thank you very much for your patch, I verified with Apple Magic Mouse
and 10.5 Leopard and it works perfect, will try at home using
MacBook’s trackpad and also on 10.6 Snow Leopard and if it works as
well, this patch can be comminted to SDL repo.
PavelOn 9.5.2010, at 7:07, Jjgod Jiang wrote:
Hi Pavel,
On Sat, May 8, 2010 at 4:53 PM, Pavel Kanzelsberger <@Pavel_Kanzelsberger> wrote:
I’m not sure how is it right now, but it’s better if Windows are
Cocoa and not something else (foreign, Carbon, whatever), so you
can access the NSWindow class, and also I think SDL is using a
CGContext from NSView right? For example I’m reusing the very same
context for rendering texts using CoreText and so on…As I understand SDL does not use the CGContext from NSView directly,
it will create a NSWindow for rendering, and NSWindow will create a
NSView as its default content view. Then SDL will create a
NSOpenGLContext and set its view as that content view.The right mouse event handling is different in Cocoa because it is
expected to show the context menu. So NSView will intercept it.See attached patch for a simple fix.
- Jiang
_______________________________________________
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Pavel Kanzelsberger
E-Mail: pavel at kanzelsberger.com
Jabber: kanzelsberger at jabber.org, ICQ: 20990633
Hi,
I can try doing a context menu, because I didn’t try that yet with
Cocoa windows. My original idea was to create a special NSView just
for the menu, or maybe there’s other way of creating context menus.
Will play with this stuff a little bit more tonight and will let you
know if something works or not.
PavelOn 9.5.2010, at 7:13, Jjgod Jiang wrote:
Hi,
On Sat, May 8, 2010 at 4:35 PM, Sam Lantinga wrote:
Which works better when interacting with foreign windows or
integrated
into a Cocoa UI?That’s what I’d like to ask too. Pavel seemed to have a perfect
application
for this so his usage pattern should be valuable. The fix I just
sent will
leave everything in foreign windows as is but make the windows
created by
SDL correctly emit right mouse down events. I hope that’s enough for
Pavel’s
need. However, if he wants to integrate a context menu (NSMenu in
Cocoa)
with the window created by SDL, my solution will not be very handy
to use.
In that case, we may want to allow the application to pass a custom
NSView
as the content view of a SDL window.
- Jiang
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Pavel Kanzelsberger
E-Mail: pavel at kanzelsberger.com
Jabber: kanzelsberger at jabber.org, ICQ: 20990633
Hello,
just to let you know, I verified Jiang’s patch on 10.6 Leopard in 64-bit mode and with macbook’s trackpad. Everything works perfect and right mouse button is reported now. Patch could be commited to HG repository.
PavelOn 10.5.2010, at 16:06, Pavel Kanzelsberger wrote:
Hello Jiang,
thank you very much for your patch, I verified with Apple Magic Mouse and 10.5 Leopard and it works perfect, will try at home using MacBook’s trackpad and also on 10.6 Snow Leopard and if it works as well, this patch can be comminted to SDL repo.
Pavel
On 9.5.2010, at 7:07, Jjgod Jiang wrote:
Hi Pavel,
On Sat, May 8, 2010 at 4:53 PM, Pavel Kanzelsberger <@Pavel_Kanzelsberger> wrote:
I’m not sure how is it right now, but it’s better if Windows are Cocoa and not something else (foreign, Carbon, whatever), so you can access the NSWindow class, and also I think SDL is using a CGContext from NSView right? For example I’m reusing the very same context for rendering texts using CoreText and so on…
As I understand SDL does not use the CGContext from NSView directly,
it will create a NSWindow for rendering, and NSWindow will create a
NSView as its default content view. Then SDL will create a
NSOpenGLContext and set its view as that content view.The right mouse event handling is different in Cocoa because it is
expected to show the context menu. So NSView will intercept it.See attached patch for a simple fix.
- Jiang
<fix-rightmousedown.patch>_______________________________________________
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Pavel Kanzelsberger
http://www.kanzelsberger.com
E-Mail: pavel at kanzelsberger.com
Jabber: kanzelsberger at jabber.org, ICQ: 20990633