To that end, most of the existing APIs are stable, and we’ll only change
them if it’s critical.
There are a few things which are still being considered, such as the iOS
event handling, and touch/mouse event semantics, but by and large the API
is set for release.
Please note, the
SDL_DROPFILE and XDnD are not compatible.
I know this have been asked before, but just to make it clear… Wouldn’t
it be possible to expose a subset of XDnD functionality as SDL_DROPFILE?
I.e. have SDL2 manage all the details (reject everything but files,
accept files, issue SDL_DROPFILE event) ?–
driedfruit
Drag and drop is not
available at all for X11 users. The drag and drop is currently
available in SDL 2.0 for Microsoft Windows users and Apple OSX users
via SDL_DROPFILE event. The SDL_DROPFILE event does not trigger in
X11 based systems such as Linux and BSDs.
I developed the drag
and drop patch for SDL 2.0 to solve this issue for X11 users. My
patch is based on the XDnD protocol. The XDnD is the de facto
protocol for drag and drop for X11 based systems.
Please note, the
SDL_DROPFILE and XDnD are not compatible. The SDL_DROPFILE is a drop
event information receiving mechanism, whereas, the XDnD is a
conversation protocol to get the drag event information converted to
an interested data format and retrieve the data of the drop either
before the mouse button is released or after the mouse button is
released at the choice of the application. The application may also
choose to not to accept the drop!
Therefore, the
SDL_DROPFILE event cannot be meaningfully issued during an XDnD
conversation.
For the benefit of X11
users, what I see is support both SDL_DROPFILE (for Windows and OSX
users) and XDnD (for X11 users) in SDL. So that Windows, OSX and X11
have a way to receive a drag and drop, rather than none at all for
X11 users.
Since XDnD is a
protocol, Windows and OSX may support it in their file managers etc.
to have an uniform drag and drop handling. But what if they do not
want to support?
Sagara________________________________
From: Sam Lantinga
To: A list for developers using the SDL library. (includes SDL-announce)
Sent: Monday, February 18, 2013 7:19 AM
Subject: [SDL] SDL 2.0 API stabilization
We’re on the road to release for SDL 2.0.
To that end, most of the existing APIs are stable, and we’ll only change them if it’s critical.
There are a few things which are still being considered, such as the iOS event handling, and touch/mouse event semantics, but by and large the API is set for release.
Yes, this is technically feasible. Its really not a subset, SDL can then implement only one data type. Support “text/uri-list”. That is, you can only drag and drop one or more files or a URL, not other types. I see this as a more sensible compromise.
Sagara________________________________
From: Driedfruit
To: sdl at lists.libsdl.org
Cc: Sagara Wijetunga <@Sagara_Wijetunga>
Sent: Wednesday, February 20, 2013 10:36 PM
Subject: Re: [SDL] SDL 2.0 API stabilization
Please note, the
SDL_DROPFILE and XDnD are not compatible.
I know this have been asked before, but just to make it clear… Wouldn’t
it be possible to expose a subset of XDnD functionality as SDL_DROPFILE?
I.e. have SDL2 manage all the details (reject everything but files,
accept files, issue SDL_DROPFILE event) ?
happy danceOn Mon, Feb 18, 2013 at 8:19 AM, Sam Lantinga wrote:
We’re on the road to release for SDL 2.0.
To that end, most of the existing APIs are stable, and we’ll only change
them if it’s critical.
There are a few things which are still being considered, such as the iOS
event handling, and touch/mouse event semantics, but by and large the API
is set for release.
Yep, let’s go with this option for now. If someone is interested enough in
the expanded protocol to implement it for Mac OS X and Windows, then let’s
look at that post 2.0.On Fri, Feb 22, 2013 at 3:11 AM, Sagara Wijetunga wrote:
Yes, this is technically feasible. Its really not a subset, SDL can then
implement only one data type. Support “text/uri-list”. That is, you can
only drag and drop one or more files or a URL, not other types. I see this
as a more sensible compromise.
Sagara
From: Driedfruit To: sdl at lists.libsdl.org Cc: Sagara Wijetunga Sent: Wednesday, February 20, 2013 10:36 PM Subject: Re: [SDL] SDL 2.0 API stabilization
Please note, the
SDL_DROPFILE and XDnD are not compatible.
I know this have been asked before, but just to make it clear… Wouldn’t
it be possible to expose a subset of XDnD functionality as SDL_DROPFILE?
I.e. have SDL2 manage all the details (reject everything but files,
accept files, issue SDL_DROPFILE event) ?
To that end, most of the existing APIs are stable, and we’ll only change them if it’s critical.
There are a few things which are still being considered, such as the iOS event handling, and touch/mouse event semantics, but by and large the API is set for release.
Sam, I suppose you are aware that SDL2 for Android is far from perfect? Only some renderer techniques are actually working, and at that they only behave as expected on some phones and tablets. Still SDL2 in this respect seems to be the most advanced on the planet: I tried Allegro (claims to have solutions, but does not work at all) and SFML (only proof of concepts).
I submitted 1 or 2 minor patches to bugzilla, and also sent a proposal regarding native sound to you which must be in the pipeline yet. Also there is a good solution to render TTF fonts using .ttf files that are already present in an Android phone or tablet.
Part of the problems is that much depends on the low-level implementations by the OEM’s, which of course are secret. They will have to be reverse-engeneered. Personally I am in the phase: If my own application works on my own tablet then I am happy. However if I find any silver bullet, then bugzilla will be the first to know it!
To that end, most of the existing APIs are stable, and we’ll only change
them if it’s critical.
There are a few things which are still being considered, such as the iOS
event handling, and touch/mouse event semantics, but by and large the API
is set for release.
Sam, I suppose you are aware that SDL2 for Android is far from perfect?
Only some renderer techniques are actually working, and at that they only
behave as expected on some phones and tablets. […]
Can you expand on this? As far as I know the Android backend is on equal
footing with the other backends.
If you refer to this issue you reported, http://bugzilla.libsdl.org/show_bug.cgi?id=1710 as I said I’m not convinced
the problem is with SDL, and if it were it can no be considered a release
stopping bug, IMO. If there are other problems, let us know.
Can you expand on this? As far as I know the Android backend is on equal footing with the other backends.
If you refer to this issue you reported, http://bugzilla.libsdl.org/show_bug.cgi?id=1710 as I said I’m not convinced the problem is with SDL, and if it were it can no be considered a release stopping bug, IMO. If there are other problems, let us know.
Hi Gabriel,
In the bug report that you refer to I proposed a solution for bad behaviour of SDL for Android. In brief: After initialization, the screen of an Android tablet is drawn correctly, but as soon you touch it, it turns to black. Only the widgets that are redrawn show up. Older tablets do not demonstrate this failure, but e.g. the screen of the Nexus 7 always seems to alternate between 2 different pixel buffers.
The solution that I described on bugzilla boiled down to give the SDL rendering thread more time to initialize. Later I found that this only worked on my own tablet. As I described in a former post to this forum I made a habit of going to a big store where you can play with gadgets unattendedly. There I installed from internet an app from my homepage, to investigate how it behaved on a specific tablet. I found different kinds of bizar behaviour. I had a discussion about this with o.a. Philipp Wiesemann, but no explanation or remedy.
After
a second thought regarding the Drag-and-Drop support in SDL, I want
to highlight that we should take a decision based on broader public
good and should set a precedent.
In
the words of the XDnD: ?The basic requirements for such a protocol
are that it provide visual feedback to the user during the drag and
that it allow the target to choose whatever data format it prefers
from among all the formats that the source can provide. In addition,
it must be efficient so that the visual feedback does not lag behind
the user’s actions, and it must be safe from deadlock, race
conditions, and other hazards inherent in asynchronous systems.?
XDnD
in nutshell is described here:
It
is obvious, supporting XDnD facilitates incentives for innovative
applications to emerge.
In
my opinion, SDL should switch to XDnD as the preferred protocol for
Drag-and-Drop for all operating system and keep the SDL_DROPFILE as a
fall back option for systems where XDnD is yet to support in source
side.
Supporting
XDnD in SDL for Unix systems, at first, it is possible applications
with richer functionality to offer to Unix-based systems. This itself
provide an incentive, though small, attract users of insecure
operating systems to switch to Unix-based systems.
Note,
XDnD is not a one sided implementation. That is, for two applications
to communicate via XDnD, it requires to be implemented in both SDL
and in the source application (eg. file browser, web browser, etc.).
XDnD
is already fully supported (i.e. Implemented in both sides) in all
Unix-based systems such as all Linux OSs, BSDs, etc. KDE, Gnome,
Firefox, Opera, etc. support XDnD. More detailed list is here: http://www.newplanetsoftware.com/xdnd/supporters.html
So
as a summary, XDnD in Unix is already covered, it must be not so
difficult to support in both MS Windows and OSX. Switching to XDnD
benefit all. My patch can be used as a base or guideline to support
XDnD for both MS Windows and OSX in relevant places in SDL.
Supporting XDnD and SDL_DROPFILE in SDL is really the way forward.
Supporting only SDL_DROPFILE in SDL, nobody may bother to support
real XDnD in SDL in future.
Sagara________________________________
From: Sam Lantinga
To: Sagara Wijetunga <@Sagara_Wijetunga>; SDL Development List
Sent: Saturday, February 23, 2013 5:08 AM
Subject: Re: [SDL] SDL 2.0 API stabilization
Yep, let’s go with this option for now. If someone is interested enough in the expanded protocol to implement it for Mac OS X and Windows, then let’s look at that post 2.0.
On Fri, Feb 22, 2013 at 3:11 AM, Sagara Wijetunga <@Sagara_Wijetunga> wrote:
Yes, this is technically feasible. Its really not a subset, SDL can then implement only one data type. Support “text/uri-list”. That is, you can only drag and drop one or more files or a URL, not other types. I see this as a more sensible compromise.
Sagara
From: Driedfruit
To: sdl at lists.libsdl.org
Cc: Sagara Wijetunga <@Sagara_Wijetunga>
Sent: Wednesday, February 20, 2013 10:36 PM
Subject: Re: [SDL] SDL 2.0 API stabilization
Please note, the
SDL_DROPFILE and XDnD are not compatible.
I know this have been asked before, but just to make it clear… Wouldn’t
it be possible to expose a subset of XDnD functionality as SDL_DROPFILE?
I.e. have SDL2 manage all the details (reject everything but files,
accept files, issue SDL_DROPFILE event) ?
I have a few local GameController API changes that do some subtle changes to the API naming, but mostly adjusting some structs to support future non-api breaking functionality I’m working on.
I’ll get those sorted out next week and up for review as I’d like to get those in NOW.On Feb 18, 2013, at 2:19 , Sam Lantinga wrote:
We’re on the road to release for SDL 2.0.
To that end, most of the existing APIs are stable, and we’ll only change them if it’s critical.
There are a few things which are still being considered, such as the iOS event handling, and touch/mouse event semantics, but by and large the API is set for release.
We really should stop thinking of this as XDnD and more of “advanced
drag and drop”.
I’d propose to add events that match XDnD’s functionality like e.g.
SDL_DRAG for when the mouse is dragging something over the SDL window
(probably with some flag to specify whether the drag is into the
window or out from it). Dropping may be somewhat less trivial as we
need to come up with a way to let the program choose between all the
formats, but I’d assume it’d involve a SDL_DROP event.
Also I’d propose adding a SDL_DROPTEXT event similar to SDL_DROPFILE
but for plain text. Would be more of a convenience event than
anything, since I can see that event being another potential common
case for drag and drop. If you need more than what those two provide
then you’d use the full SDL_DROP event.
Should drag and drop enhancements be put in 2.0 or be left for 2.1?
2013/2/28, Sagara Wijetunga :>
After
a second thought regarding the Drag-and-Drop support in SDL, I want
to highlight that we should take a decision based on broader public
good and should set a precedent.
In
the words of the XDnD: ?The basic requirements for such a protocol
are that it provide visual feedback to the user during the drag and
that it allow the target to choose whatever data format it prefers
from among all the formats that the source can provide. In addition,
it must be efficient so that the visual feedback does not lag behind
the user’s actions, and it must be safe from deadlock, race
conditions, and other hazards inherent in asynchronous systems.?
It
is obvious, supporting XDnD facilitates incentives for innovative
applications to emerge.
In
my opinion, SDL should switch to XDnD as the preferred protocol for
Drag-and-Drop for all operating system and keep the SDL_DROPFILE as a
fall back option for systems where XDnD is yet to support in source
side.
Supporting
XDnD in SDL for Unix systems, at first, it is possible applications
with richer functionality to offer to Unix-based systems. This itself
provide an incentive, though small, attract users of insecure
operating systems to switch to Unix-based systems.
Note,
XDnD is not a one sided implementation. That is, for two applications
to communicate via XDnD, it requires to be implemented in both SDL
and in the source application (eg. file browser, web browser, etc.).
XDnD
is already fully supported (i.e. Implemented in both sides) in all
Unix-based systems such as all Linux OSs, BSDs, etc. KDE, Gnome,
Firefox, Opera, etc. support XDnD. More detailed list is here: http://www.newplanetsoftware.com/xdnd/supporters.html
So
as a summary, XDnD in Unix is already covered, it must be not so
difficult to support in both MS Windows and OSX. Switching to XDnD
benefit all. My patch can be used as a base or guideline to support
XDnD for both MS Windows and OSX in relevant places in SDL.
Supporting XDnD and SDL_DROPFILE in SDL is really the way forward.
Supporting only SDL_DROPFILE in SDL, nobody may bother to support
real XDnD in SDL in future.
Sagara
From: Sam Lantinga
To: Sagara Wijetunga ; SDL Development List
Sent: Saturday, February 23, 2013 5:08 AM
Subject: Re: [SDL] SDL 2.0 API stabilization
Yep, let’s go with this option for now. If someone is interested enough in
the expanded protocol to implement it for Mac OS X and Windows, then let’s
look at that post 2.0.
On Fri, Feb 22, 2013 at 3:11 AM, Sagara Wijetunga wrote:
Yes, this is technically feasible. Its really not a subset, SDL can then
implement only one data type. Support “text/uri-list”. That is, you can only
drag and drop one or more files or a URL, not other types. I see this as a
more sensible compromise.
Sagara
From: Driedfruit
To: sdl at lists.libsdl.org
Cc: Sagara Wijetunga
Sent: Wednesday, February 20, 2013 10:36 PM
Subject: Re: [SDL] SDL 2.0 API stabilization
Please note, the
SDL_DROPFILE and XDnD are not compatible.
I know this have been asked before, but just to make it clear… Wouldn’t
it be possible to expose a subset of XDnD functionality as SDL_DROPFILE?
I.e. have SDL2 manage all the details (reject everything but files,
accept files, issue SDL_DROPFILE event) ?
The motivation is that developers cannot currently write a portable event loop
in SDL2 if they want to support touch events.On 02/18/2013 02:19 AM, Sam Lantinga wrote:
We’re on the road to release for SDL 2.0.
To that end, most of the existing APIs are stable, and we’ll only change them if
it’s critical.
There are a few things which are still being considered, such as the iOS event
handling, and touch/mouse event semantics, but by and large the API is set for
release.
Another option is to default touch events off, and deliver mouse events if
they are off, and touch events if they are enabled.On Sat, Mar 2, 2013 at 9:50 AM, John wrote:
The motivation is that developers cannot currently write a portable event
loop in SDL2 if they want to support touch events.
On 02/18/2013 02:19 AM, Sam Lantinga wrote:
We’re on the road to release for SDL 2.0.
To that end, most of the existing APIs are stable, and we’ll only change
them if
it’s critical.
There are a few things which are still being considered, such as the iOS
event
handling, and touch/mouse event semantics, but by and large the API is
set for
release.
The motivation is that developers cannot currently write a portable event
loop in SDL2 if they want to support touch events.
On 02/18/2013 02:19 AM, Sam Lantinga wrote:
We’re on the road to release for SDL 2.0.
To that end, most of the existing APIs are stable, and we’ll only change
them if
it’s critical.
There are a few things which are still being considered, such as the iOS
event
handling, and touch/mouse event semantics, but by and large the API is
set for
release.
I have a few local GameController API changes that do some subtle changes to the API naming, but mostly adjusting some structs to support future non-api breaking functionality I’m working on.
I’ll get those sorted out next week and up for review as I’d like to get those in NOW.
You can now tell if a mouse event was simulated by touch input. The mouse
event has a new ‘which’ field and is set to the value SDL_TOUCH_MOUSEID.
I talked it over with Ryan and this was the best solution which didn’t
involve unexpected behavior changes and still allowed smart applications to
do the right thing.
Cheers!On Sat, Mar 2, 2013 at 10:38 AM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:
So basically SDL_INIT_TOUCH? (if a program acknowledges it supports
touch there isn’t any reason to emulate touch events)
2013/3/2, Sam Lantinga <@slouken>:
I agree, this needs to be addressed.
Another option is to default touch events off, and deliver mouse events
if
they are off, and touch events if they are enabled.
Yeah, that seems better. I realized later that SDL_INIT_TOUCH would
result in programs using SDL_INIT_EVERYTHING to not get emulated touch
input, but I was away by then (honestly using SDL_INIT_EVERYTHING
isn’t a good idea in the first place, but eh)
2013/3/3, Sam Lantinga :> You can now tell if a mouse event was simulated by touch input. The mouse
event has a new ‘which’ field and is set to the value SDL_TOUCH_MOUSEID.
I talked it over with Ryan and this was the best solution which didn’t
involve unexpected behavior changes and still allowed smart applications to
do the right thing.
Cheers!
On Sat, Mar 2, 2013 at 10:38 AM, Sik the hedgehog < @Sik_the_hedgehog> wrote:
So basically SDL_INIT_TOUCH? (if a program acknowledges it supports
touch there isn’t any reason to emulate touch events)
2013/3/2, Sam Lantinga :
I agree, this needs to be addressed.
Another option is to default touch events off, and deliver mouse events
if
they are off, and touch events if they are enabled.
Does the mouse state become affected by delivery of the simulated events? i.e.,
will touch events now alter the mouse state?On 03/03/2013 12:09 AM, Sik the hedgehog wrote:
Yeah, that seems better. I realized later that SDL_INIT_TOUCH would
result in programs using SDL_INIT_EVERYTHING to not get emulated touch
input, but I was away by then (honestly using SDL_INIT_EVERYTHING
isn’t a good idea in the first place, but eh)
2013/3/3, Sam Lantinga :
You can now tell if a mouse event was simulated by touch input. The mouse
event has a new ‘which’ field and is set to the value SDL_TOUCH_MOUSEID.
I talked it over with Ryan and this was the best solution which didn’t
involve unexpected behavior changes and still allowed smart applications to
do the right thing.
Cheers!
On Sat, Mar 2, 2013 at 10:38 AM, Sik the hedgehog < sik.the.hedgehog at gmail.com> wrote:
So basically SDL_INIT_TOUCH? (if a program acknowledges it supports
touch there isn’t any reason to emulate touch events)
2013/3/2, Sam Lantinga :
I agree, this needs to be addressed.
Another option is to default touch events off, and deliver mouse events
if
they are off, and touch events if they are enabled.
On Sat, Mar 2, 2013 at 9:50 AM, John <@John6> wrote:
What states could be affected? May want to narrow down the specific
issues that could arise before trying to discuss what to do about it.
2013/3/3, John :> Does the mouse state become affected by delivery of the simulated events?
i.e.,
will touch events now alter the mouse state?
On 03/03/2013 12:09 AM, Sik the hedgehog wrote:
Yeah, that seems better. I realized later that SDL_INIT_TOUCH would
result in programs using SDL_INIT_EVERYTHING to not get emulated touch
input, but I was away by then (honestly using SDL_INIT_EVERYTHING
isn’t a good idea in the first place, but eh)
2013/3/3, Sam Lantinga :
You can now tell if a mouse event was simulated by touch input. The
mouse
event has a new ‘which’ field and is set to the value
SDL_TOUCH_MOUSEID.
I talked it over with Ryan and this was the best solution which didn’t
involve unexpected behavior changes and still allowed smart applications
to
do the right thing.
Cheers!
On Sat, Mar 2, 2013 at 10:38 AM, Sik the hedgehog < @Sik_the_hedgehog> wrote:
So basically SDL_INIT_TOUCH? (if a program acknowledges it supports
touch there isn’t any reason to emulate touch events)
2013/3/2, Sam Lantinga :
I agree, this needs to be addressed.
Another option is to default touch events off, and deliver mouse
events
if
they are off, and touch events if they are enabled.
(honestly using SDL_INIT_EVERYTHING