FULLSCREEN_DESKTOP. SDL 2.0.1. MacOSX.
Message-ID:
<CA+Q62MAcyKHDQ3tc0kqMBnVX1vx1E4D_Epi_MW7eAJ05EOiqTw at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I tried SDL 2.0.2 today and I get the same problem. I did some more
investigation and refined the steps to reproduce. The problem is most
easily reproduced with Mac OS X 10.9.2. It is not actually required to run
the application fullscreen as I initially thought. Here are some repro
steps for windowed mode:
- Run the SDL application in windowed mode.
- Minimise the application using the yellow minus sign at the top
left-corner of the window.
- Focus another application (e.g. click on something else such as
Terminal).
- Click on the thumbnail image of the application, just next to the Trash
can, in the dock (not than the application icon).
- Notice that the application does not receive the window focus, although
it is the active window.
So this won’t solve your problem (at least not yet) but may give some
hints. I am currently prototyping to turn SDL inside-out so 1) I can
embed SDL views in native/existing apps/frameworks, 2) use the
platform’s native event pump because the current SDL model of
explicitly pumping the event loop actually causes a lot of corner
cases which have caused things like focus problems on Mac/iOS and some
related concerns I have on Android. (I hope to start a public
proposal/discussion to the mailing list in a couple of weeks.)
Purely out of curiosity, is this looking like a SDL 2.x, or a SDL 3.x?> Date: Wed, 12 Mar 2014 21:53:02 -0700
From: Eric Wing
To: SDL Development List
Subject: Re: [SDL] No mouse events after returning to
On 3/12/14, John Knottenbelt wrote:
Purely out of curiosity, is this looking like a SDL 2.x, or a SDL 3.x?
My goal is to not break current SDL and be fully compatible with the
traditional model, so 2.x.
My idea idea is to introduce a few new API functions or initialization
flags that tell SDL to activate the alternative behaviors if wanted.
If not called, SDL behaves the same as it does now.
Then for native integration (using Cocoa/NSView/Interface Builder as
my mental model, but this can extend to all platforms), I hope to
refactor the internals slightly to allow native views to be surfaced
and accessed directly from native platform code.
(Imagine an SDLViewCocoa class in Objective-C that is an internal
implementation detail, but now we expose the header for those that
need to create an SDLView to be embedded in say a graphical Level
Designer tool that helps create levels for SDL based games. This is in
the same spirit of what Apple has done with their new SpriteKit and
Xcode designer integration. And working in scientific visualization
for a long time, this is something I have a lot of experience doing,
so I am optimistic I can pull it off with SDL.)
I don’t think the native view part will be public API, but sort of
semi-blessed APIs in the spirit of “we will try not to break these
because they are here for exactly this purpose, but if we must, we
will”. If we can get to the point where it is public API, that would
be great, but I think it will take time and experimentation from the
community.
I’m still doing prototyping to see how far I can get and what kinds of
issues surface so I can make an intelligent proposal. But I really
want the community to accept these changes (and I also really need
them), so I’m trying very hard to not scare anybody or break anybody.
I’ve probably already said too much and scared everybody. Fortunately,
GDC is next week, so probably nobody is paying any attention to this
-Eric–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
Seems a pretty good idea to me.On Fri, Mar 14, 2014 at 12:03 PM, Eric Wing wrote:
Purely out of curiosity, is this looking like a SDL 2.x, or a SDL 3.x?
My goal is to not break current SDL and be fully compatible with the
traditional model, so 2.x.
My idea idea is to introduce a few new API functions or initialization
flags that tell SDL to activate the alternative behaviors if wanted.
If not called, SDL behaves the same as it does now.
Then for native integration (using Cocoa/NSView/Interface Builder as
my mental model, but this can extend to all platforms), I hope to
refactor the internals slightly to allow native views to be surfaced
and accessed directly from native platform code.
(Imagine an SDLViewCocoa class in Objective-C that is an internal
implementation detail, but now we expose the header for those that
need to create an SDLView to be embedded in say a graphical Level
Designer tool that helps create levels for SDL based games. This is in
the same spirit of what Apple has done with their new SpriteKit and
Xcode designer integration. And working in scientific visualization
for a long time, this is something I have a lot of experience doing,
so I am optimistic I can pull it off with SDL.)
I don’t think the native view part will be public API, but sort of
semi-blessed APIs in the spirit of “we will try not to break these
because they are here for exactly this purpose, but if we must, we
will”. If we can get to the point where it is public API, that would
be great, but I think it will take time and experimentation from the
community.
I’m still doing prototyping to see how far I can get and what kinds of
issues surface so I can make an intelligent proposal. But I really
want the community to accept these changes (and I also really need
them), so I’m trying very hard to not scare anybody or break anybody.
I’ve probably already said too much and scared everybody. Fortunately,
GDC is next week, so probably nobody is paying any attention to this
-Eric
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
Pallav Nawani
IronCode Gaming Private Limited
Website: http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming
Mobile: 9997478768