to FULLSCREEN_DESKTOP. SDL 2.0.1. MacOSX.Message-ID:
<CA+Q62MCsHWbutrsLOmhv8OwJoFQowRJD5tVEEsZRW1d7Ybkf9A at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
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.
Not entirely certain what you mean, since the backends are already as
native as they need to be to access those resources. Do you mean in
the sense of allowing an app to have platform-specific code that e.g.
uses platform features in coordination with SDL features when it knows
how? That certainly seems to me like a logical evolution on the
ability to tell SDL to reset state.
(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.)
So passingly like what’s done for DirectX, though maybe more thorough?
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 pretty sure that I’ve suggested some sort of
internals-versioning-system before. This is a case where it
could/would be useful (especially since Apple seems to like changing
things). An indication of the version of the versioning system itself,
- major & extension versions for the APIs should be enough.
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),
Is this the sort of thing that should allow someone (probably other
than you or me) to extend SDL2 into supporting e.g. browser plugin
APIs as a “native platform”?> Date: Thu, 13 Mar 2014 23:33:36 -0700
From: Eric Wing
To: SDL Development List
Subject: Re: [SDL] SDL Inside-Out Was: No mouse events after returning