Patch - Drag and drop using XDND protocol on X11

Hi Sam and SDL community

The attached patch for SDL implements drag and drop using XDND protocol on X11.

XDND protocol: http://www.newplanetsoftware.com/xdnd/

The present SDL_DROPFILE event does not trigger on X11 systems such as BSD and Linux.

The SDL_DROPFILE seems to support a single file drag and drop.

Whereas, the XDND protocol on X11, supports not only single file drag and drop, it supports multiple files, text and other types of drag and drop. Therefore, more versatile.

This patch introduces a new programming interface on drag and drop on X11. Once this new programming interface is finalised and acceptable to the SDL community, I would like to see this patch is absorbed into the SDL main tree.

A summary and an example of how to use XDND-based drag and drop on X11 are also included below.

Those who are new for XDND, please read the ?Example walk-through? section from http://www.newplanetsoftware.com/xdnd/ .

Thank you.

Kind regards
Sagara Wijetunga

About the patch----------------------

  1. New set of drag and drop events have been introduced: SDL_XDNDENTER, SDL_XDNDPOSITION, SDL_XDNDLEAVE and SDL_XDNDDROP. [include/SDL_events.h]

  2. Instead of activating them individually, the patch relies on the activation of the SDL_DROPFILE.

  3. Corresponding data structures SDL_XdndEnter, SDL_XdndPosition, SDL_XdndLeave and SDL_XdndDrop have also been introduced to above new events. [include/SDL_events.h]

  4. A new SDL_WindowFlags is also introduced: SDL_WINDOW_XDNDAWARE. This new flag creates a SDL_Window which XDnD aware.

  5. Code sections may require to move to different files or to new files to suit SDL coding conventions. Also may require to update the patch to exclude compiling on non-X11 systems.

  6. When retrive data using “text/uri-list”, the returned list may be separated by newline (\n).

  7. This patch was developed and only tested on SDL 2.0.

How to apply the patch

cd SDL
patch -Np1 path-to-patch

Example

?SDL_Event??? event;
?SDL_Window window;
?SDL_SysWMinfo info;
?unsigned long int SDLWindowXID = 0; /
X Window id of the SDL Window */

?Uint8??? currentXdndProtocolVersion = 0;
?Uint32??? currentXdndDataTypeList = NULL;
?Uint32??? currentXdndNumDataTypes = 0;? /
Number of data types in currentDnDDataTypeList */
?unsigned char *currentXdndDataBuf = NULL;
?Uint32?? ??? currentXdndDataBufLen = 0;

?unsigned char *appDataBuf = NULL;
?
?int n;
?
?int curWindowPosition_x, curWindowPosition_y;
?int curWindow_w, curWindow_h;

?/* Enable SDL_DROPFILE event which is disabled by default */
?SDL_EventState(SDL_DROPFILE, SDL_ENABLE);

?/* Create the SDL_Window with XdndAware */
?window = SDL_CreateWindow(“SDL Window”, 0, 0, width, height, SDL_WINDOW_RESIZABLE | SDL_WINDOW_OPENGL | SDL_WINDOW_XDNDAWARE);

?/* Initialize info structure with SDL version info */
?SDL_VERSION(&info.version);
?
? if (SDL_GetWindowWMInfo(window, &info))
??? {
??? SDLWindowXID = (unsigned long int) info.info.x11.window;
??? }

?/* Wait for events */

?for(;:wink:
?{
? SDL_WaitEvent(&event);
?
? switch(event.type)
? {
??? case SDL_XDNDENTER:??? ?
??? if (event.xDndEnter.targetWindow == SDLWindowXID)
??? {
?? ?? printf("\n SDL_XDNDENTER \n");
?? ?? printf(“event.xDndEnter.targetWindow: %lu\n”, (unsigned long int) event.xDndEnter.targetWindow);
?? ?? printf(“SDLWindowXID: %lu\n”, (unsigned long int) SDLWindowXID);

?? ?? currentXdndProtocolVersion = event.xDndEnter.protocolVersion;
?? ? ?
?? ?? if (currentXdndDataTypeList != NULL)
?? ??? SDL_free(currentXdndDataTypeList);
?? ??? ?
?? ?? currentXdndDataTypeList??? = event.xDndEnter.dataTypeList;
?? ?? currentXdndNumDataTypes??? = event.xDndEnter.numDataTypes;? /* Number of data types in currentDnDDataTypeList */??? ?
?? ?
?? ?? printf(“sourceWindow: %d\n”, event.xDndEnter.sourceWindow);
?? ?? printf(“protocolVersion: %d\n”, event.xDndEnter.protocolVersion);
?? ?? printf(“numDataTypes: %d\n”, event.xDndEnter.numDataTypes);

?? ?? if (event.xDndEnter.dataTypeList == NULL)
?? ??? printf(“dataTypeList is NULL\n”);
??? ?
?? ?? for (n=0; n < event.xDndEnter.numDataTypes; n++)
?? ??? {
?? ??? printf(“dataType: %d - %s\n”, event.xDndEnter.dataTypeList[n],
?? ??? ?SDL_XdndGetDataTypeName(event.xDndEnter.sourceDisplay, event.xDndEnter.dataTypeList[n]));
?? ??? }
??? }
??? break;

??? case SDL_XDNDPOSITION:
??? if (event.xDndPosition.targetWindow == SDLWindowXID)
??? {
?? ?? printf("\n SDL_XDNDPOSITION \n");
?? ?? printf(“sourceWindow: %d\n”, event.xDndPosition.sourceWindow);
?? ?? printf(“X: %d\n”, event.xDndPosition.x);
?? ?? printf(“Y: %d\n”, event.xDndPosition.y);
?? ?? printf(“timeStamp: %d\n”, event.xDndPosition.timeStamp);
?? ?? printf(“actionRequested: %d\n”, event.xDndPosition.actionRequested);

?? ?? /* Call SDL_XdndXConvertSelection() is required in SDL_XDNDPOSITION */
?? ?? SDL_XdndXConvertSelection(event.xDndPosition.sourceDisplay,
?? ??? ??? ??? ??? event.xDndPosition.sourceWindow,
?? ??? ??? ??? ??? SDL_XdndGetDataType(event.xDndPosition.sourceDisplay, “text/uri-list”),
?? ??? ??? ??? ??? event.xDndPosition.timeStamp);
?? ? ?
?? ?? SDL_GetWindowPosition(window, &curWindowPosition_x, &curWindowPosition_y);
?? ?? SDL_GetWindowSize(window, &curWindow_w, &curWindow_h);

?? ?? SDL_SendXdndStatus(window, event.xDndPosition.sourceDisplay, event.xDndPosition.sourceWindow,
?? ??? ??? ??? 1, curWindowPosition_x, curWindowPosition_y,
?? ??? ??? ??? curWindow_w, curWindow_h);?? ??? ?
?? ? }
??? break;

??? case SDL_XDNDLEAVE:
??? if (event.xDndLeave.targetWindow == SDLWindowXID)
??? {
?? ?? printf("\n SDL_XDNDLEAVE \n");
?? ?? printf(“sourceWindow: %d\n”, event.xDndLeave.sourceWindow);

?? ?? if (currentXdndDataBuf != NULL)
?? ??? {
?? ??? SDL_free(currentXdndDataBuf);
?? ??? currentXdndDataBuf = NULL;
?? ??? }
?? ? }
??? break;

??? case SDL_XDNDDROP:
??? if (event.xDndDrop.targetWindow == SDLWindowXID)
??? {
?? ?? printf("\n SDL_XDNDDROP \n");
?? ?? printf(“sourceWindow: %d\n”, event.xDndDrop.sourceWindow);
?? ?? printf(“timeStamp: %d\n”, event.xDndDrop.timeStamp);
?? ??? ?
?? ?? if (appDataBuf != NULL)
?? ??? {
?? ??? SDL_free(appDataBuf);
?? ??? }

?? ?? currentXdndDataBuf = SDL_XdndGetData(event.xDndDrop.sourceDisplay,
?? ??? ??? ??? ??? event.xDndDrop.sourceWindow,
?? ??? ??? ??? ??? SDL_XdndGetDataType(event.xDndDrop.sourceDisplay, “text/uri-list”),
?? ??? ??? ??? ??? event.xDndDrop.timeStamp,
?? ??? ??? ??? ??? &currentXdndDataBufLen);

?? ?? if (currentXdndDataBuf == NULL)
?? ??? printf(“No data buffer returned!\n”);
?? ? ?
?? ?? printf(“currentXdndDataBufLen: %d\n”, currentXdndDataBufLen);
?? ? ?
?? ?? SDL_SendXdndFinished(window, event.xDndDrop.sourceDisplay, event.xDndDrop.sourceWindow,
?? ??? ??? ??? 1, currentXdndProtocolVersion);
?? ??? ??? ??? ?
?? ?? if (currentXdndDataBufLen > 0)
?? ??? {
?? ??? appDataBuf = (Uint8 ) SDL_malloc(sizeof(Uint8)(currentXdndDataBufLen+1));
?? ? ?
?? ??? if (appDataBuf != NULL)
?? ??? ? {
?? ??? ?? for (n=0; n < currentXdndDataBufLen; n++)
?? ??? ??? {
?? ??? ??? appDataBuf[n] = currentXdndDataBuf[n];
?? ??? ??? }
?? ??? ?
?? ??? ?? appDataBuf[currentXdndDataBufLen] = ‘\0’;
?? ??? ?? SDL_free(currentXdndDataBuf);
?? ??? ?? currentXdndDataBuf = NULL;
?? ??? ? ?
?? ??? ?? printf(“Data: %s\n”, appDataBuf);
?? ??? ? }
?? ??? }
?? ? }
??? break;

? }
}

==============
-------------- next part --------------
A non-text attachment was scrubbed…
Name: SDL-XDND-2013-Feb-11.patch
Type: application/octet-stream
Size: 20143 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130211/59c1acc6/attachment-0001.obj

Is there a way to generalize this implementation for Mac OS X and Windows?

If that’s not possible, is it possible to internalize the protocol possibly
with some media handling registration, and then leave the SDL_DROPFILE as
the single event API?

Thanks!On Mon, Feb 11, 2013 at 10:22 AM, Sagara Wijetunga wrote:

Hi Sam and SDL community

The attached patch for SDL implements drag and drop using XDND protocol on
X11.

XDND protocol: http://www.newplanetsoftware.com/xdnd/

The present SDL_DROPFILE event does not trigger on X11 systems such as BSD
and Linux.

The SDL_DROPFILE seems to support a single file drag and drop.

Whereas, the XDND protocol on X11, supports not only single file drag and
drop, it supports multiple files, text and other types of drag and drop.
Therefore, more versatile.

This patch introduces a new programming interface on drag and drop on X11.
Once this new programming interface is finalised and acceptable to the SDL
community, I would like to see this patch is absorbed into the SDL main
tree.

A summary and an example of how to use XDND-based drag and drop on X11 are
also included below.

Those who are new for XDND, please read the ?Example walk-through? section
from http://www.newplanetsoftware.com/xdnd/ .

Thank you.

Kind regards
Sagara Wijetunga

About the patch

  1. New set of drag and drop events have been introduced: SDL_XDNDENTER,
    SDL_XDNDPOSITION, SDL_XDNDLEAVE and SDL_XDNDDROP. [include/SDL_events.h]

  2. Instead of activating them individually, the patch relies on the
    activation of the SDL_DROPFILE.

  3. Corresponding data structures SDL_XdndEnter, SDL_XdndPosition,
    SDL_XdndLeave and SDL_XdndDrop have also been introduced to above new
    events. [include/SDL_events.h]

  4. A new SDL_WindowFlags is also introduced: SDL_WINDOW_XDNDAWARE. This
    new flag creates a SDL_Window which XDnD aware.

  5. Code sections may require to move to different files or to new files to
    suit SDL coding conventions. Also may require to update the patch to
    exclude compiling on non-X11 systems.

  6. When retrive data using “text/uri-list”, the returned list may be
    separated by newline (\n).

  7. This patch was developed and only tested on SDL 2.0.

How to apply the patch

cd SDL
patch -Np1 path-to-patch

Example

SDL_Event event;
SDL_Window window;
SDL_SysWMinfo info;
unsigned long int SDLWindowXID = 0; /
X Window id of the SDL Window */

Uint8 currentXdndProtocolVersion = 0;
Uint32 currentXdndDataTypeList = NULL;
Uint32 currentXdndNumDataTypes = 0; /
Number of data types in
currentDnDDataTypeList */
unsigned char *currentXdndDataBuf = NULL;
Uint32 currentXdndDataBufLen = 0;

unsigned char *appDataBuf = NULL;

int n;

int curWindowPosition_x, curWindowPosition_y;
int curWindow_w, curWindow_h;

/* Enable SDL_DROPFILE event which is disabled by default */
SDL_EventState(SDL_DROPFILE, SDL_ENABLE);

/* Create the SDL_Window with XdndAware */
window = SDL_CreateWindow(“SDL Window”, 0, 0, width, height,
SDL_WINDOW_RESIZABLE | SDL_WINDOW_OPENGL | SDL_WINDOW_XDNDAWARE);

/* Initialize info structure with SDL version info */
SDL_VERSION(&info.version);

if (SDL_GetWindowWMInfo(window, &info))
{
SDLWindowXID = (unsigned long int) info.info.x11.window;
}

/* Wait for events */

for(;:wink:
{
SDL_WaitEvent(&event);

switch(event.type)
{
case SDL_XDNDENTER:
if (event.xDndEnter.targetWindow == SDLWindowXID)
{
printf("\n SDL_XDNDENTER \n");
printf(“event.xDndEnter.targetWindow: %lu\n”, (unsigned long int)
event.xDndEnter.targetWindow);
printf(“SDLWindowXID: %lu\n”, (unsigned long int) SDLWindowXID);

  currentXdndProtocolVersion = event.xDndEnter.protocolVersion;

  if (currentXdndDataTypeList != NULL)
     SDL_free(currentXdndDataTypeList);

  currentXdndDataTypeList    = event.xDndEnter.dataTypeList;
  currentXdndNumDataTypes    = event.xDndEnter.numDataTypes;  /*

Number of data types in currentDnDDataTypeList */

  printf("sourceWindow: %d\n", event.xDndEnter.sourceWindow);
  printf("protocolVersion: %d\n", event.xDndEnter.protocolVersion);
  printf("numDataTypes: %d\n", event.xDndEnter.numDataTypes);

  if (event.xDndEnter.dataTypeList == NULL)
      printf("dataTypeList is NULL\n");

  for (n=0; n < event.xDndEnter.numDataTypes; n++)
      {
       printf("dataType: %d - %s\n", event.xDndEnter.dataTypeList[n],
    SDL_XdndGetDataTypeName(event.xDndEnter.sourceDisplay,

event.xDndEnter.dataTypeList[n]));
}
}
break;

case SDL_XDNDPOSITION:
  if (event.xDndPosition.targetWindow == SDLWindowXID)
     {
  printf("\n SDL_XDNDPOSITION \n");
  printf("sourceWindow: %d\n", event.xDndPosition.sourceWindow);
  printf("X: %d\n", event.xDndPosition.x);
  printf("Y: %d\n", event.xDndPosition.y);
  printf("timeStamp: %d\n", event.xDndPosition.timeStamp);
  printf("actionRequested: %d\n", event.xDndPosition.actionRequested);

  /* Call SDL_XdndXConvertSelection() is required in SDL_XDNDPOSITION

*/
SDL_XdndXConvertSelection(event.xDndPosition.sourceDisplay,
event.xDndPosition.sourceWindow,
SDL_XdndGetDataType(event.xDndPosition.sourceDisplay,
“text/uri-list”),
event.xDndPosition.timeStamp);

  SDL_GetWindowPosition(window, &curWindowPosition_x,

&curWindowPosition_y);
SDL_GetWindowSize(window, &curWindow_w, &curWindow_h);

  SDL_SendXdndStatus(window, event.xDndPosition.sourceDisplay,

event.xDndPosition.sourceWindow,
1, curWindowPosition_x, curWindowPosition_y,
curWindow_w, curWindow_h);
}
break;

case SDL_XDNDLEAVE:
  if (event.xDndLeave.targetWindow == SDLWindowXID)
     {
  printf("\n SDL_XDNDLEAVE \n");
  printf("sourceWindow: %d\n", event.xDndLeave.sourceWindow);

  if (currentXdndDataBuf != NULL)
     {
      SDL_free(currentXdndDataBuf);
      currentXdndDataBuf = NULL;
     }
 }
  break;

case SDL_XDNDDROP:
  if (event.xDndDrop.targetWindow == SDLWindowXID)
     {
  printf("\n SDL_XDNDDROP \n");
  printf("sourceWindow: %d\n", event.xDndDrop.sourceWindow);
  printf("timeStamp: %d\n", event.xDndDrop.timeStamp);

  if (appDataBuf != NULL)
     {
      SDL_free(appDataBuf);
     }

  currentXdndDataBuf = SDL_XdndGetData(event.xDndDrop.sourceDisplay,
                event.xDndDrop.sourceWindow,
                SDL_XdndGetDataType(event.xDndDrop.sourceDisplay,

“text/uri-list”),
event.xDndDrop.timeStamp,
&currentXdndDataBufLen);

  if (currentXdndDataBuf == NULL)
      printf("No data buffer returned!\n");

  printf("currentXdndDataBufLen: %d\n", currentXdndDataBufLen);

  SDL_SendXdndFinished(window, event.xDndDrop.sourceDisplay,

event.xDndDrop.sourceWindow,
1, currentXdndProtocolVersion);

  if (currentXdndDataBufLen > 0)
     {
      appDataBuf = (Uint8 *)

SDL_malloc(sizeof(Uint8)*(currentXdndDataBufLen+1));

      if (appDataBuf != NULL)
     {
      for (n=0; n < currentXdndDataBufLen; n++)
          {
           appDataBuf[n] = currentXdndDataBuf[n];
          }

      appDataBuf[currentXdndDataBufLen] = '\0';
      SDL_free(currentXdndDataBuf);
      currentXdndDataBuf = NULL;

      printf("Data: %s\n", appDataBuf);
     }
     }
 }
  break;

}
}

==============


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

We can look at this
problem in few different ways.

First of all,
SDL_DROPFILE and XDnD can co-exists. That is, SDL_DROPFILE can be
used on MS Windows and OSX, and XDnD can be used on X11. The X11 guys
will enjoy a richer functionality :slight_smile:

Second, SDL_DROPFILE
and XDnD are conceptually different. The SDL_DROPFILE is used to
receive a drop event after the mouse button is released, whereas XDnD
is a communication dialogue mechanism comprising series of events,
first receive a notification (XdndEnter) that somebody is trying to
drop something (eg. a single file, collection of files, text, etc.)
before the mouse button is released. This XdndEnter notification
(SDL_XDNDENTER) is sent from a source window (eg. a file browser,
text editor, etc.) to a target window (eg. our SDL application). The
XdndEnter event contain most importantly the data types (represented
in MIME formats) supported by the source window (eg. text/plain,
text/uri-list, etc.). That is, the source can send data in those
formats. Next, the source window sends the XdndPosition
(SDL_XDNDPOSITION) event indicating the position the user trying to
drop. Note, unlike in SDL_DROPFILE, but in XDnD, at this point of
time, before even receive the data, the target window or our SDL
application now has an opportunity to inspect the data types,
position, etc. and decide to accept or reject the drop. At this point
of time, the target window or our SDL application also has an
opportunity to visually indicate whether it is willing to accept or
reject the drop. At the XdndPosition stage, the target application
may retrieve data and inspect to accept or reject the drop before
even user release the mouse button. The target window or our SDL
application can continue the conversation with the source window to
get the data of the drop converted to a suitable format (eg. file
name or file contents, textual or binary data) and finally retrieve
the data and conclude the conversation.

Therefore, SDL_DROPFILE
and XDnD are two different things and SDL_DROPFILE alone is
insufficient to represent the XDnD conversation. Note, it is the
target window or the SDL application decides whether to accept or
reject the drop, not the SDL itself makes this decision.

I do not think XDnD is
X11/Unix specific though the name of the protocol is ?Drag-and-Drop
Protocol for the X Window System?. If the MS Windows or Apple OSX
wishes to support XDnD protocol in their file browsers and in other
applications (if not already supported), its a matter of they
generate relevant events as per the XDnD protocol from their file
browsers and other applications. Nowhere in the XDnD protocol
mentioned the protocol is patented. So nothing seems to prevent
anybody implement XDnD protocol.

In my opinion, rather
than we wait until big players implement XDnD protocol, lets offer
X11 guys the XDnD and SDL_DROPFILE for Windows and OSX guys, as XDnD
does not conflict with SDL_DROPFILE. Once big players implements
XDnD, you may deprecate the SDL_DROPFILE.

Kind regards
Sagara________________________________
From: slouken@libsdl.org (slouken)
To: Sagara Wijetunga <@Sagara_Wijetunga>; SDL Development List
Sent: Tuesday, February 12, 2013 12:38 AM
Subject: Re: [SDL] Patch - Drag and drop using XDND protocol on X11

Is there a way to generalize this implementation for Mac OS X and Windows?

If that’s not possible, is it possible to internalize the protocol possibly with some media handling registration, and then leave the SDL_DROPFILE as the single event API?

Thanks!

On Mon, Feb 11, 2013 at 10:22 AM, Sagara Wijetunga <@Sagara_Wijetunga> wrote:

Hi Sam and SDL community

The attached patch for SDL implements drag and drop using XDND protocol on X11.

XDND protocol: http://www.newplanetsoftware.com/xdnd/

The present SDL_DROPFILE event does not trigger on X11 systems such as BSD and Linux.

The SDL_DROPFILE seems to support a single file drag and drop.

Whereas, the XDND protocol on X11, supports not only single file drag and drop, it supports multiple files, text and other types of drag and drop. Therefore, more versatile.

This patch introduces a new programming interface on drag and drop on X11. Once this new programming interface is finalised and acceptable to the SDL community, I would like to see this patch is absorbed into the SDL main tree.

A summary and an example of how to use XDND-based drag and drop on X11 are also included below.

Those who are new for XDND, please read the ?Example walk-through? section from http://www.newplanetsoftware.com/xdnd/ .

Thank you.

Kind regards
Sagara Wijetunga

About the patch

  1. New set of drag and drop events have been introduced: SDL_XDNDENTER, SDL_XDNDPOSITION, SDL_XDNDLEAVE and SDL_XDNDDROP. [include/SDL_events.h]

  2. Instead of activating them individually, the patch relies on the activation of the SDL_DROPFILE.

  3. Corresponding data structures SDL_XdndEnter, SDL_XdndPosition, SDL_XdndLeave and SDL_XdndDrop have also been introduced to above new events. [include/SDL_events.h]

  4. A new SDL_WindowFlags is also introduced: SDL_WINDOW_XDNDAWARE. This new flag creates a SDL_Window which XDnD aware.

  5. Code sections may require to move to different files or to new files to suit SDL coding conventions. Also may require to update the patch to exclude compiling on non-X11 systems.

  6. When retrive data using “text/uri-list”, the returned list may be separated by newline (\n).

  7. This patch was developed and only tested on SDL 2.0.

How to apply the patch

cd SDL
patch -Np1 path-to-patch

Example

?SDL_Event??? event;
?SDL_Window window;
?SDL_SysWMinfo info;
?unsigned long int SDLWindowXID = 0; /
X Window id of the SDL Window */

?Uint8??? currentXdndProtocolVersion = 0;
?Uint32??? currentXdndDataTypeList = NULL;
?Uint32??? currentXdndNumDataTypes = 0;? /
Number of data types in currentDnDDataTypeList */
?unsigned char *currentXdndDataBuf = NULL;
?Uint32?? ??? currentXdndDataBufLen = 0;

?unsigned char *appDataBuf = NULL;
?
?int n;
?
?int curWindowPosition_x, curWindowPosition_y;
?int curWindow_w, curWindow_h;

?/* Enable SDL_DROPFILE event which is disabled by default */
?SDL_EventState(SDL_DROPFILE, SDL_ENABLE);

?/* Create the SDL_Window with XdndAware */
?window = SDL_CreateWindow(“SDL Window”, 0, 0, width, height, SDL_WINDOW_RESIZABLE | SDL_WINDOW_OPENGL | SDL_WINDOW_XDNDAWARE);

?/* Initialize info structure with SDL version info */
?SDL_VERSION(&info.version);
?
? if (SDL_GetWindowWMInfo(window, &info))
??? {
??? SDLWindowXID = (unsigned long int) info.info.x11.window;
??? }

?/* Wait for events */

?for(;:wink:
?{
? SDL_WaitEvent(&event);
?
? switch(event.type)
? {
??? case SDL_XDNDENTER:??? ?
??? if (event.xDndEnter.targetWindow == SDLWindowXID)
??? {
?? ?? printf("\n SDL_XDNDENTER \n");
?? ?? printf(“event.xDndEnter.targetWindow: %lu\n”, (unsigned long int) event.xDndEnter.targetWindow);
?? ?? printf(“SDLWindowXID: %lu\n”, (unsigned long int) SDLWindowXID);

?? ?? currentXdndProtocolVersion = event.xDndEnter.protocolVersion;
?? ? ?
?? ?? if (currentXdndDataTypeList != NULL)
?? ??? SDL_free(currentXdndDataTypeList);
?? ??? ?
?? ?? currentXdndDataTypeList??? = event.xDndEnter.dataTypeList;
?? ?? currentXdndNumDataTypes??? = event.xDndEnter.numDataTypes;? /* Number of data types in currentDnDDataTypeList */??? ?
?? ?
?? ?? printf(“sourceWindow: %d\n”, event.xDndEnter.sourceWindow);
?? ?? printf(“protocolVersion: %d\n”, event.xDndEnter.protocolVersion);
?? ?? printf(“numDataTypes: %d\n”, event.xDndEnter.numDataTypes);

?? ?? if (event.xDndEnter.dataTypeList == NULL)
?? ??? printf(“dataTypeList is NULL\n”);
??? ?
?? ?? for (n=0; n < event.xDndEnter.numDataTypes; n++)
?? ??? {
?? ??? printf(“dataType: %d - %s\n”, event.xDndEnter.dataTypeList[n],
?? ??? ?SDL_XdndGetDataTypeName(event.xDndEnter.sourceDisplay, event.xDndEnter.dataTypeList[n]));
?? ??? }
??? }
??? break;

??? case SDL_XDNDPOSITION:
??? if (event.xDndPosition.targetWindow == SDLWindowXID)
??? {
?? ?? printf("\n SDL_XDNDPOSITION \n");
?? ?? printf(“sourceWindow: %d\n”, event.xDndPosition.sourceWindow);
?? ?? printf(“X: %d\n”, event.xDndPosition.x);
?? ?? printf(“Y: %d\n”, event.xDndPosition.y);
?? ?? printf(“timeStamp: %d\n”, event.xDndPosition.timeStamp);
?? ?? printf(“actionRequested: %d\n”, event.xDndPosition.actionRequested);

?? ?? /* Call SDL_XdndXConvertSelection() is required in SDL_XDNDPOSITION */
?? ?? SDL_XdndXConvertSelection(event.xDndPosition.sourceDisplay,
?? ??? ??? ??? ??? event.xDndPosition.sourceWindow,
?? ??? ??? ??? ??? SDL_XdndGetDataType(event.xDndPosition.sourceDisplay, “text/uri-list”),
?? ??? ??? ??? ??? event.xDndPosition.timeStamp);
?? ? ?
?? ?? SDL_GetWindowPosition(window, &curWindowPosition_x, &curWindowPosition_y);
?? ?? SDL_GetWindowSize(window, &curWindow_w, &curWindow_h);

?? ?? SDL_SendXdndStatus(window, event.xDndPosition.sourceDisplay, event.xDndPosition.sourceWindow,
?? ??? ??? ??? 1, curWindowPosition_x, curWindowPosition_y,
?? ??? ??? ??? curWindow_w, curWindow_h);?? ??? ?
?? ? }
??? break;

??? case SDL_XDNDLEAVE:
??? if (event.xDndLeave.targetWindow == SDLWindowXID)
??? {
?? ?? printf("\n SDL_XDNDLEAVE \n");
?? ?? printf(“sourceWindow: %d\n”, event.xDndLeave.sourceWindow);

?? ?? if (currentXdndDataBuf != NULL)
?? ??? {
?? ??? SDL_free(currentXdndDataBuf);
?? ??? currentXdndDataBuf = NULL;
?? ??? }
?? ? }
??? break;

??? case SDL_XDNDDROP:
??? if (event.xDndDrop.targetWindow == SDLWindowXID)
??? {
?? ?? printf("\n SDL_XDNDDROP \n");
?? ?? printf(“sourceWindow: %d\n”, event.xDndDrop.sourceWindow);
?? ?? printf(“timeStamp: %d\n”, event.xDndDrop.timeStamp);
?? ??? ?
?? ?? if (appDataBuf != NULL)
?? ??? {
?? ??? SDL_free(appDataBuf);
?? ??? }

?? ?? currentXdndDataBuf = SDL_XdndGetData(event.xDndDrop.sourceDisplay,
?? ??? ??? ??? ??? event.xDndDrop.sourceWindow,
?? ??? ??? ??? ??? SDL_XdndGetDataType(event.xDndDrop.sourceDisplay, “text/uri-list”),
?? ??? ??? ??? ??? event.xDndDrop.timeStamp,
?? ??? ??? ??? ??? &currentXdndDataBufLen);

?? ?? if (currentXdndDataBuf == NULL)
?? ??? printf(“No data buffer returned!\n”);
?? ? ?
?? ?? printf(“currentXdndDataBufLen: %d\n”, currentXdndDataBufLen);
?? ? ?
?? ?? SDL_SendXdndFinished(window, event.xDndDrop.sourceDisplay, event.xDndDrop.sourceWindow,
?? ??? ??? ??? 1, currentXdndProtocolVersion);
?? ??? ??? ??? ?
?? ?? if (currentXdndDataBufLen > 0)
?? ??? {
?? ??? appDataBuf = (Uint8 ) SDL_malloc(sizeof(Uint8)(currentXdndDataBufLen+1));
?? ? ?
?? ??? if (appDataBuf != NULL)
?? ??? ? {
?? ??? ?? for (n=0; n < currentXdndDataBufLen; n++)
?? ??? ??? {
?? ??? ??? appDataBuf[n] = currentXdndDataBuf[n];
?? ??? ??? }
?? ??? ?
?? ??? ?? appDataBuf[currentXdndDataBufLen] = ‘\0’;
?? ??? ?? SDL_free(currentXdndDataBuf);
?? ??? ?? currentXdndDataBuf = NULL;
?? ??? ? ?
?? ??? ?? printf(“Data: %s\n”, appDataBuf);
?? ??? ? }
?? ??? }
?? ? }
??? break;

? }
}

==============


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

This looks like a good way forward for drag and drop. We could genericize
the events a little more (i.e. SDL_DNDENTER, SDL_DNDPOSITION, SDL_DNDLEAVE)
and only send SDL_DROPFILE (or SDL_DNDDROP) on platforms that don’t support
such events. SDL_XDNDPOSITION is used to tell the target window where the
cursor is because the source window still has focus, right? How compatible
is the received data with SDL_DROPFILE? Is it the important part just a
file URL that is received?

Jonny DOn Tue, Feb 12, 2013 at 5:12 AM, Sagara Wijetunga wrote:

We can look at this
problem in few different ways.

First of all,
SDL_DROPFILE and XDnD can co-exists. That is, SDL_DROPFILE can be
used on MS Windows and OSX, and XDnD can be used on X11. The X11 guys
will enjoy a richer functionality :slight_smile:

Second, SDL_DROPFILE
and XDnD are conceptually different. The SDL_DROPFILE is used to
receive a drop event after the mouse button is released, whereas XDnD
is a communication dialogue mechanism comprising series of events,
first receive a notification (XdndEnter) that somebody is trying to
drop something (eg. a single file, collection of files, text, etc.)
before the mouse button is released. This XdndEnter notification
(SDL_XDNDENTER) is sent from a source window (eg. a file browser,
text editor, etc.) to a target window (eg. our SDL application). The
XdndEnter event contain most importantly the data types (represented
in MIME formats) supported by the source window (eg. text/plain,
text/uri-list, etc.). That is, the source can send data in those
formats. Next, the source window sends the XdndPosition
(SDL_XDNDPOSITION) event indicating the position the user trying to
drop. Note, unlike in SDL_DROPFILE, but in XDnD, at this point of
time, before even receive the data, the target window or our SDL
application now has an opportunity to inspect the data types,
position, etc. and decide to accept or reject the drop. At this point
of time, the target window or our SDL application also has an
opportunity to visually indicate whether it is willing to accept or
reject the drop. At the XdndPosition stage, the target application
may retrieve data and inspect to accept or reject the drop before
even user release the mouse button. The target window or our SDL
application can continue the conversation with the source window to
get the data of the drop converted to a suitable format (eg. file
name or file contents, textual or binary data) and finally retrieve
the data and conclude the conversation.

Therefore, SDL_DROPFILE
and XDnD are two different things and SDL_DROPFILE alone is
insufficient to represent the XDnD conversation. Note, it is the
target window or the SDL application decides whether to accept or
reject the drop, not the SDL itself makes this decision.

I do not think XDnD is
X11/Unix specific though the name of the protocol is ?Drag-and-Drop
Protocol for the X Window System?. If the MS Windows or Apple OSX
wishes to support XDnD protocol in their file browsers and in other
applications (if not already supported), its a matter of they
generate relevant events as per the XDnD protocol from their file
browsers and other applications. Nowhere in the XDnD protocol
mentioned the protocol is patented. So nothing seems to prevent
anybody implement XDnD protocol.

In my opinion, rather
than we wait until big players implement XDnD protocol, lets offer
X11 guys the XDnD and SDL_DROPFILE for Windows and OSX guys, as XDnD
does not conflict with SDL_DROPFILE. Once big players implements
XDnD, you may deprecate the SDL_DROPFILE.

Kind regards
Sagara


From: Sam Lantinga
To: Sagara Wijetunga ; SDL Development List <
sdl at lists.libsdl.org>
Sent: Tuesday, February 12, 2013 12:38 AM
Subject: Re: [SDL] Patch - Drag and drop using XDND protocol on X11

Is there a way to generalize this implementation for Mac OS X and Windows?

If that’s not possible, is it possible to internalize the protocol
possibly with some media handling registration, and then leave the
SDL_DROPFILE as the single event API?

Thanks!

On Mon, Feb 11, 2013 at 10:22 AM, Sagara Wijetunga wrote:

Hi Sam and SDL community

The attached patch for SDL implements drag and drop using XDND protocol
on X11.

XDND protocol: http://www.newplanetsoftware.com/xdnd/

The present SDL_DROPFILE event does not trigger on X11 systems such as
BSD and Linux.

The SDL_DROPFILE seems to support a single file drag and drop.

Whereas, the XDND protocol on X11, supports not only single file drag and
drop, it supports multiple files, text and other types of drag and drop.
Therefore, more versatile.

This patch introduces a new programming interface on drag and drop on
X11. Once this new programming interface is finalised and acceptable to the
SDL community, I would like to see this patch is absorbed into the SDL main
tree.

A summary and an example of how to use XDND-based drag and drop on X11
are also included below.

Those who are new for XDND, please read the ?Example walk-through?
section from http://www.newplanetsoftware.com/xdnd/ .

Thank you.

Kind regards
Sagara Wijetunga

About the patch

  1. New set of drag and drop events have been introduced: SDL_XDNDENTER,
    SDL_XDNDPOSITION, SDL_XDNDLEAVE and SDL_XDNDDROP. [include/SDL_events.h]

  2. Instead of activating them individually, the patch relies on the
    activation of the SDL_DROPFILE.

  3. Corresponding data structures SDL_XdndEnter, SDL_XdndPosition,
    SDL_XdndLeave and SDL_XdndDrop have also been introduced to above new
    events. [include/SDL_events.h]

  4. A new SDL_WindowFlags is also introduced: SDL_WINDOW_XDNDAWARE. This
    new flag creates a SDL_Window which XDnD aware.

  5. Code sections may require to move to different files or to new files
    to suit SDL coding conventions. Also may require to update the patch to
    exclude compiling on non-X11 systems.

  6. When retrive data using “text/uri-list”, the returned list may be
    separated by newline (\n).

  7. This patch was developed and only tested on SDL 2.0.

How to apply the patch

cd SDL
patch -Np1 path-to-patch

Example

SDL_Event event;
SDL_Window window;
SDL_SysWMinfo info;
unsigned long int SDLWindowXID = 0; /
X Window id of the SDL Window */

Uint8 currentXdndProtocolVersion = 0;
Uint32 currentXdndDataTypeList = NULL;
Uint32 currentXdndNumDataTypes = 0; /
Number of data types in
currentDnDDataTypeList */
unsigned char *currentXdndDataBuf = NULL;
Uint32 currentXdndDataBufLen = 0;

unsigned char *appDataBuf = NULL;

int n;

int curWindowPosition_x, curWindowPosition_y;
int curWindow_w, curWindow_h;

/* Enable SDL_DROPFILE event which is disabled by default */
SDL_EventState(SDL_DROPFILE, SDL_ENABLE);

/* Create the SDL_Window with XdndAware */
window = SDL_CreateWindow(“SDL Window”, 0, 0, width, height,
SDL_WINDOW_RESIZABLE | SDL_WINDOW_OPENGL | SDL_WINDOW_XDNDAWARE);

/* Initialize info structure with SDL version info */
SDL_VERSION(&info.version);

if (SDL_GetWindowWMInfo(window, &info))
{
SDLWindowXID = (unsigned long int) info.info.x11.window;
}

/* Wait for events */

for(;:wink:
{
SDL_WaitEvent(&event);

switch(event.type)
{
case SDL_XDNDENTER:
if (event.xDndEnter.targetWindow == SDLWindowXID)
{
printf("\n SDL_XDNDENTER \n");
printf(“event.xDndEnter.targetWindow: %lu\n”, (unsigned long int)
event.xDndEnter.targetWindow);
printf(“SDLWindowXID: %lu\n”, (unsigned long int) SDLWindowXID);

 currentXdndProtocolVersion = event.xDndEnter.protocolVersion;

 if (currentXdndDataTypeList != NULL)
    SDL_free(currentXdndDataTypeList);

 currentXdndDataTypeList    = event.xDndEnter.dataTypeList;
 currentXdndNumDataTypes    = event.xDndEnter.numDataTypes;  /*

Number of data types in currentDnDDataTypeList */

 printf("sourceWindow: %d\n", event.xDndEnter.sourceWindow);
 printf("protocolVersion: %d\n", event.xDndEnter.protocolVersion);
 printf("numDataTypes: %d\n", event.xDndEnter.numDataTypes);

 if (event.xDndEnter.dataTypeList == NULL)
     printf("dataTypeList is NULL\n");

 for (n=0; n < event.xDndEnter.numDataTypes; n++)
     {
      printf("dataType: %d - %s\n", event.xDndEnter.dataTypeList[n],
   SDL_XdndGetDataTypeName(event.xDndEnter.sourceDisplay,

event.xDndEnter.dataTypeList[n]));

     }
 }
 break;

case SDL_XDNDPOSITION:
if (event.xDndPosition.targetWindow == SDLWindowXID)
{
printf("\n SDL_XDNDPOSITION \n");
printf(“sourceWindow: %d\n”, event.xDndPosition.sourceWindow);
printf(“X: %d\n”, event.xDndPosition.x);
printf(“Y: %d\n”, event.xDndPosition.y);
printf(“timeStamp: %d\n”, event.xDndPosition.timeStamp);
printf(“actionRequested: %d\n”, event.xDndPosition.actionRequested);

 /* Call SDL_XdndXConvertSelection() is required in SDL_XDNDPOSITION

*/

 SDL_XdndXConvertSelection(event.xDndPosition.sourceDisplay,
               event.xDndPosition.sourceWindow,
               SDL_XdndGetDataType(event.xDndPosition.sourceDisplay,

“text/uri-list”),

               event.xDndPosition.timeStamp);

 SDL_GetWindowPosition(window, &curWindowPosition_x,

&curWindowPosition_y);

 SDL_GetWindowSize(window, &curWindow_w, &curWindow_h);

 SDL_SendXdndStatus(window, event.xDndPosition.sourceDisplay,

event.xDndPosition.sourceWindow,

            1, curWindowPosition_x, curWindowPosition_y,
            curWindow_w, curWindow_h);
}
 break;

case SDL_XDNDLEAVE:
if (event.xDndLeave.targetWindow == SDLWindowXID)
{
printf("\n SDL_XDNDLEAVE \n");
printf(“sourceWindow: %d\n”, event.xDndLeave.sourceWindow);

 if (currentXdndDataBuf != NULL)
    {
     SDL_free(currentXdndDataBuf);
     currentXdndDataBuf = NULL;
    }
}
 break;

case SDL_XDNDDROP:
if (event.xDndDrop.targetWindow == SDLWindowXID)
{
printf("\n SDL_XDNDDROP \n");
printf(“sourceWindow: %d\n”, event.xDndDrop.sourceWindow);
printf(“timeStamp: %d\n”, event.xDndDrop.timeStamp);

 if (appDataBuf != NULL)
    {
     SDL_free(appDataBuf);
    }

 currentXdndDataBuf = SDL_XdndGetData(event.xDndDrop.sourceDisplay,
               event.xDndDrop.sourceWindow,
               SDL_XdndGetDataType(event.xDndDrop.sourceDisplay,

“text/uri-list”),

               event.xDndDrop.timeStamp,
               &currentXdndDataBufLen);

 if (currentXdndDataBuf == NULL)
     printf("No data buffer returned!\n");

 printf("currentXdndDataBufLen: %d\n", currentXdndDataBufLen);

 SDL_SendXdndFinished(window, event.xDndDrop.sourceDisplay,

event.xDndDrop.sourceWindow,

            1, currentXdndProtocolVersion);

 if (currentXdndDataBufLen > 0)
    {
     appDataBuf = (Uint8 *)

SDL_malloc(sizeof(Uint8)*(currentXdndDataBufLen+1));

     if (appDataBuf != NULL)
    {
     for (n=0; n < currentXdndDataBufLen; n++)
         {
          appDataBuf[n] = currentXdndDataBuf[n];
         }

     appDataBuf[currentXdndDataBufLen] = '\0';
     SDL_free(currentXdndDataBuf);
     currentXdndDataBuf = NULL;

     printf("Data: %s\n", appDataBuf);
    }
    }
}
 break;

}
}

==============


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Compatibility of “received” data cannot compare to SDL_DROPFILE. In XDnD data are not received in first place. Data are retrieved at user’s discretion either at SDL_XDNDPOSITION time or at SDL_XDNDDROP time. If the data already retrieved at the SDL_XDNDPOSITION time, you don’t retrieve again at the SDL_XDNDDROP time.

Whereas, SDL_DROPFILE may be issued once the user released the mouse button. In XDnD, user may retrieve data before the mouse button is released.

In SDL_DROPFILE, user receive a file URL and the user has no opportunity to specify the type of the data. In XDnD user request the data to be sent in the format he wants by specifying the MIME type.

In XDnD user may receive a buffer with one file URL or a buffer with thousands of file URLs separated by newlines (\n) (or other separator) or a buffer with text with newlines (\n).

With “text/uri-list” you know you get a list of file URLs, and with “text/plain” you know get a story. With other supported MIME types, a user can receive data in different formats.

Sagara________________________________
From: Jonathan Dearborn
To: Sagara Wijetunga <@Sagara_Wijetunga>; SDL Development List
Sent: Tuesday, February 12, 2013 1:30 PM
Subject: Re: [SDL] Patch - Drag and drop using XDND protocol on X11

This looks like a good way forward for drag and drop. ?We could genericize the events a little more (i.e. SDL_DNDENTER, SDL_DNDPOSITION, SDL_DNDLEAVE) and only send SDL_DROPFILE (or SDL_DNDDROP) on platforms that don’t support such events. ?SDL_XDNDPOSITION is used to tell the target window where the cursor is because the source window still has focus, right? ?How compatible is the received data with SDL_DROPFILE? ?Is it the important part just a file URL that is received?

Jonny D

On Tue, Feb 12, 2013 at 5:12 AM, Sagara Wijetunga <@Sagara_Wijetunga> wrote:

We can look at this
problem in few different ways.

First of all,
SDL_DROPFILE and XDnD can co-exists. That is, SDL_DROPFILE can be
used on MS Windows and OSX, and XDnD can be used on X11. The X11 guys
will enjoy a richer functionality :slight_smile:

Second, SDL_DROPFILE
and XDnD are conceptually different. The SDL_DROPFILE is used to
receive a drop event after the mouse button is released, whereas XDnD
is a communication dialogue mechanism comprising series of events,
first receive a notification (XdndEnter) that somebody is trying to
drop something (eg. a single file, collection of files, text, etc.)
before the mouse button is released. This XdndEnter notification
(SDL_XDNDENTER) is sent from a source window (eg. a file browser,
text editor, etc.) to a target window (eg. our SDL application). The
XdndEnter event contain most importantly the data types (represented
in MIME formats) supported by the source window (eg. text/plain,
text/uri-list, etc.). That is, the source can send data in those
formats. Next, the source window sends the XdndPosition
(SDL_XDNDPOSITION) event indicating the position the user trying to
drop. Note, unlike in SDL_DROPFILE, but in XDnD, at this point of
time, before even receive the data, the target window or our SDL
application now has an opportunity to inspect the data types,
position, etc. and decide to accept or reject the drop. At this point
of time, the target window or our SDL application also has an
opportunity to visually indicate whether it is willing to accept or
reject the drop. At the XdndPosition stage, the target application
may retrieve data and inspect to accept or reject the drop before
even user release the mouse button. The target window or our SDL
application can continue the conversation with the source window to
get the data of the drop converted to a suitable format (eg. file
name or file contents, textual or binary data) and finally retrieve
the data and conclude the conversation.

Therefore, SDL_DROPFILE
and XDnD are two different things and SDL_DROPFILE alone is
insufficient to represent the XDnD conversation. Note, it is the
target window or the SDL application decides whether to accept or
reject the drop, not the SDL itself makes this decision.

I do not think XDnD is
X11/Unix specific though the name of the protocol is ?Drag-and-Drop
Protocol for the X Window System?. If the MS Windows or Apple OSX
wishes to support XDnD protocol in their file browsers and in other
applications (if not already supported), its a matter of they
generate relevant events as per the XDnD protocol from their file
browsers and other applications. Nowhere in the XDnD protocol
mentioned the protocol is patented. So nothing seems to prevent
anybody implement XDnD protocol.

In my opinion, rather
than we wait until big players implement XDnD protocol, lets offer
X11 guys the XDnD and SDL_DROPFILE for Windows and OSX guys, as XDnD
does not conflict with SDL_DROPFILE. Once big players implements
XDnD, you may deprecate the SDL_DROPFILE.

Kind regards
Sagara

I think the point was that SDL_DROPFILE could be compared to
SDL_XDNDDROP (when it involves a file).

2013/2/12, Sagara Wijetunga :> Compatibility of “received” data cannot compare to SDL_DROPFILE. In XDnD

data are not received in first place. Data are retrieved at user’s
discretion either at SDL_XDNDPOSITION time or at SDL_XDNDDROP time. If the
data already retrieved at the SDL_XDNDPOSITION time, you don’t retrieve
again at the SDL_XDNDDROP time.

Whereas, SDL_DROPFILE may be issued once the user released the mouse button.
In XDnD, user may retrieve data before the mouse button is released.

In SDL_DROPFILE, user receive a file URL and the user has no opportunity to
specify the type of the data. In XDnD user request the data to be sent in
the format he wants by specifying the MIME type.

In XDnD user may receive a buffer with one file URL or a buffer with
thousands of file URLs separated by newlines (\n) (or other separator) or a
buffer with text with newlines (\n).

With “text/uri-list” you know you get a list of file URLs, and with
"text/plain" you know get a story. With other supported MIME types, a user
can receive data in different formats.

Sagara


From: Jonathan Dearborn
To: Sagara Wijetunga ; SDL Development List

Sent: Tuesday, February 12, 2013 1:30 PM
Subject: Re: [SDL] Patch - Drag and drop using XDND protocol on X11

This looks like a good way forward for drag and drop. ?We could genericize
the events a little more (i.e. SDL_DNDENTER, SDL_DNDPOSITION, SDL_DNDLEAVE)
and only send SDL_DROPFILE (or SDL_DNDDROP) on platforms that don’t support
such events. ?SDL_XDNDPOSITION is used to tell the target window where the
cursor is because the source window still has focus, right? ?How compatible
is the received data with SDL_DROPFILE? ?Is it the important part just a
file URL that is received?

Jonny D

On Tue, Feb 12, 2013 at 5:12 AM, Sagara Wijetunga wrote:

We can look at this
problem in few different ways.

First of all,
SDL_DROPFILE and XDnD can co-exists. That is, SDL_DROPFILE can be
used on MS Windows and OSX, and XDnD can be used on X11. The X11 guys
will enjoy a richer functionality :slight_smile:

Second, SDL_DROPFILE
and XDnD are conceptually different. The SDL_DROPFILE is used to
receive a drop event after the mouse button is released, whereas XDnD
is a communication dialogue mechanism comprising series of events,
first receive a notification (XdndEnter) that somebody is trying to
drop something (eg. a single file, collection of files, text, etc.)
before the mouse button is released. This XdndEnter notification
(SDL_XDNDENTER) is sent from a source window (eg. a file browser,
text editor, etc.) to a target window (eg. our SDL application). The
XdndEnter event contain most importantly the data types (represented
in MIME formats) supported by the source window (eg. text/plain,
text/uri-list, etc.). That is, the source can send data in those
formats. Next, the source window sends the XdndPosition
(SDL_XDNDPOSITION) event indicating the position the user trying to
drop. Note, unlike in SDL_DROPFILE, but in XDnD, at this point of
time, before even receive the data, the target window or our SDL
application now has an opportunity to inspect the data types,
position, etc. and decide to accept or reject the drop. At this point
of time, the target window or our SDL application also has an
opportunity to visually indicate whether it is willing to accept or
reject the drop. At the XdndPosition stage, the target application
may retrieve data and inspect to accept or reject the drop before
even user release the mouse button. The target window or our SDL
application can continue the conversation with the source window to
get the data of the drop converted to a suitable format (eg. file
name or file contents, textual or binary data) and finally retrieve
the data and conclude the conversation.

Therefore, SDL_DROPFILE
and XDnD are two different things and SDL_DROPFILE alone is
insufficient to represent the XDnD conversation. Note, it is the
target window or the SDL application decides whether to accept or
reject the drop, not the SDL itself makes this decision.

I do not think XDnD is
X11/Unix specific though the name of the protocol is ?Drag-and-Drop
Protocol for the X Window System?. If the MS Windows or Apple OSX
wishes to support XDnD protocol in their file browsers and in other
applications (if not already supported), its a matter of they
generate relevant events as per the XDnD protocol from their file
browsers and other applications. Nowhere in the XDnD protocol
mentioned the protocol is patented. So nothing seems to prevent
anybody implement XDnD protocol.

In my opinion, rather
than we wait until big players implement XDnD protocol, lets offer
X11 guys the XDnD and SDL_DROPFILE for Windows and OSX guys, as XDnD
does not conflict with SDL_DROPFILE. Once big players implements
XDnD, you may deprecate the SDL_DROPFILE.

Kind regards
Sagara

This KIND of thing is of course supported on Windows and Mac (content-type
negotiation between producers and consumers of drag/drop data), and has been for
a very long time. So it should be possible for SDL to support a portable API
for DnD rather than expose X11-specific functionality.

Is DnD useful for games? Would a portable GUI widget framework be more suitable
for such apps that need DnD, rather than SDL?On 02/12/2013 12:55 PM, Sik the hedgehog wrote:

I think the point was that SDL_DROPFILE could be compared to
SDL_XDNDDROP (when it involves a file).

2013/2/12, Sagara Wijetunga :

Compatibility of “received” data cannot compare to SDL_DROPFILE. In XDnD
data are not received in first place. Data are retrieved at user’s
discretion either at SDL_XDNDPOSITION time or at SDL_XDNDDROP time. If the
data already retrieved at the SDL_XDNDPOSITION time, you don’t retrieve
again at the SDL_XDNDDROP time.

Whereas, SDL_DROPFILE may be issued once the user released the mouse button.
In XDnD, user may retrieve data before the mouse button is released.

In SDL_DROPFILE, user receive a file URL and the user has no opportunity to
specify the type of the data. In XDnD user request the data to be sent in
the format he wants by specifying the MIME type.

In XDnD user may receive a buffer with one file URL or a buffer with
thousands of file URLs separated by newlines (\n) (or other separator) or a
buffer with text with newlines (\n).

With “text/uri-list” you know you get a list of file URLs, and with
"text/plain" you know get a story. With other supported MIME types, a user
can receive data in different formats.

Sagara


From: Jonathan Dearborn
To: Sagara Wijetunga ; SDL Development List

Sent: Tuesday, February 12, 2013 1:30 PM
Subject: Re: [SDL] Patch - Drag and drop using XDND protocol on X11

This looks like a good way forward for drag and drop. We could genericize
the events a little more (i.e. SDL_DNDENTER, SDL_DNDPOSITION, SDL_DNDLEAVE)
and only send SDL_DROPFILE (or SDL_DNDDROP) on platforms that don’t support
such events. SDL_XDNDPOSITION is used to tell the target window where the
cursor is because the source window still has focus, right? How compatible
is the received data with SDL_DROPFILE? Is it the important part just a
file URL that is received?

Jonny D

On Tue, Feb 12, 2013 at 5:12 AM, Sagara Wijetunga wrote:

We can look at this
problem in few different ways.

First of all,
SDL_DROPFILE and XDnD can co-exists. That is, SDL_DROPFILE can be
used on MS Windows and OSX, and XDnD can be used on X11. The X11 guys
will enjoy a richer functionality :slight_smile:

Second, SDL_DROPFILE
and XDnD are conceptually different. The SDL_DROPFILE is used to
receive a drop event after the mouse button is released, whereas XDnD
is a communication dialogue mechanism comprising series of events,
first receive a notification (XdndEnter) that somebody is trying to
drop something (eg. a single file, collection of files, text, etc.)
before the mouse button is released. This XdndEnter notification
(SDL_XDNDENTER) is sent from a source window (eg. a file browser,
text editor, etc.) to a target window (eg. our SDL application). The
XdndEnter event contain most importantly the data types (represented
in MIME formats) supported by the source window (eg. text/plain,
text/uri-list, etc.). That is, the source can send data in those
formats. Next, the source window sends the XdndPosition
(SDL_XDNDPOSITION) event indicating the position the user trying to
drop. Note, unlike in SDL_DROPFILE, but in XDnD, at this point of
time, before even receive the data, the target window or our SDL
application now has an opportunity to inspect the data types,
position, etc. and decide to accept or reject the drop. At this point
of time, the target window or our SDL application also has an
opportunity to visually indicate whether it is willing to accept or
reject the drop. At the XdndPosition stage, the target application
may retrieve data and inspect to accept or reject the drop before
even user release the mouse button. The target window or our SDL
application can continue the conversation with the source window to
get the data of the drop converted to a suitable format (eg. file
name or file contents, textual or binary data) and finally retrieve
the data and conclude the conversation.

Therefore, SDL_DROPFILE
and XDnD are two different things and SDL_DROPFILE alone is
insufficient to represent the XDnD conversation. Note, it is the
target window or the SDL application decides whether to accept or
reject the drop, not the SDL itself makes this decision.

I do not think XDnD is
X11/Unix specific though the name of the protocol is ?Drag-and-Drop
Protocol for the X Window System?. If the MS Windows or Apple OSX
wishes to support XDnD protocol in their file browsers and in other
applications (if not already supported), its a matter of they
generate relevant events as per the XDnD protocol from their file
browsers and other applications. Nowhere in the XDnD protocol
mentioned the protocol is patented. So nothing seems to prevent
anybody implement XDnD protocol.

In my opinion, rather
than we wait until big players implement XDnD protocol, lets offer
X11 guys the XDnD and SDL_DROPFILE for Windows and OSX guys, as XDnD
does not conflict with SDL_DROPFILE. Once big players implements
XDnD, you may deprecate the SDL_DROPFILE.

Kind regards
Sagara


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I assume it can be useful for games that implement their own UI -
especially dropping of text.

2013/2/12, John :> This KIND of thing is of course supported on Windows and Mac (content-type

negotiation between producers and consumers of drag/drop data), and has been
for
a very long time. So it should be possible for SDL to support a portable
API
for DnD rather than expose X11-specific functionality.

Is DnD useful for games? Would a portable GUI widget framework be more
suitable
for such apps that need DnD, rather than SDL?

On 02/12/2013 12:55 PM, Sik the hedgehog wrote:

I think the point was that SDL_DROPFILE could be compared to
SDL_XDNDDROP (when it involves a file).

2013/2/12, Sagara Wijetunga :

Compatibility of “received” data cannot compare to SDL_DROPFILE. In XDnD
data are not received in first place. Data are retrieved at user’s
discretion either at SDL_XDNDPOSITION time or at SDL_XDNDDROP time. If
the
data already retrieved at the SDL_XDNDPOSITION time, you don’t retrieve
again at the SDL_XDNDDROP time.

Whereas, SDL_DROPFILE may be issued once the user released the mouse
button.
In XDnD, user may retrieve data before the mouse button is released.

In SDL_DROPFILE, user receive a file URL and the user has no opportunity
to
specify the type of the data. In XDnD user request the data to be sent
in
the format he wants by specifying the MIME type.

In XDnD user may receive a buffer with one file URL or a buffer with
thousands of file URLs separated by newlines (\n) (or other separator) or
a
buffer with text with newlines (\n).

With “text/uri-list” you know you get a list of file URLs, and with
"text/plain" you know get a story. With other supported MIME types, a
user
can receive data in different formats.

Sagara


From: Jonathan Dearborn
To: Sagara Wijetunga ; SDL Development List

Sent: Tuesday, February 12, 2013 1:30 PM
Subject: Re: [SDL] Patch - Drag and drop using XDND protocol on X11

This looks like a good way forward for drag and drop. We could
genericize
the events a little more (i.e. SDL_DNDENTER, SDL_DNDPOSITION,
SDL_DNDLEAVE)
and only send SDL_DROPFILE (or SDL_DNDDROP) on platforms that don’t
support
such events. SDL_XDNDPOSITION is used to tell the target window where
the
cursor is because the source window still has focus, right? How
compatible
is the received data with SDL_DROPFILE? Is it the important part just a
file URL that is received?

Jonny D

On Tue, Feb 12, 2013 at 5:12 AM, Sagara Wijetunga wrote:

We can look at this
problem in few different ways.

First of all,
SDL_DROPFILE and XDnD can co-exists. That is, SDL_DROPFILE can be
used on MS Windows and OSX, and XDnD can be used on X11. The X11 guys
will enjoy a richer functionality :slight_smile:

Second, SDL_DROPFILE
and XDnD are conceptually different. The SDL_DROPFILE is used to
receive a drop event after the mouse button is released, whereas XDnD
is a communication dialogue mechanism comprising series of events,
first receive a notification (XdndEnter) that somebody is trying to
drop something (eg. a single file, collection of files, text, etc.)
before the mouse button is released. This XdndEnter notification
(SDL_XDNDENTER) is sent from a source window (eg. a file browser,
text editor, etc.) to a target window (eg. our SDL application). The
XdndEnter event contain most importantly the data types (represented
in MIME formats) supported by the source window (eg. text/plain,
text/uri-list, etc.). That is, the source can send data in those
formats. Next, the source window sends the XdndPosition
(SDL_XDNDPOSITION) event indicating the position the user trying to
drop. Note, unlike in SDL_DROPFILE, but in XDnD, at this point of
time, before even receive the data, the target window or our SDL
application now has an opportunity to inspect the data types,
position, etc. and decide to accept or reject the drop. At this point
of time, the target window or our SDL application also has an
opportunity to visually indicate whether it is willing to accept or
reject the drop. At the XdndPosition stage, the target application
may retrieve data and inspect to accept or reject the drop before
even user release the mouse button. The target window or our SDL
application can continue the conversation with the source window to
get the data of the drop converted to a suitable format (eg. file
name or file contents, textual or binary data) and finally retrieve
the data and conclude the conversation.

Therefore, SDL_DROPFILE
and XDnD are two different things and SDL_DROPFILE alone is
insufficient to represent the XDnD conversation. Note, it is the
target window or the SDL application decides whether to accept or
reject the drop, not the SDL itself makes this decision.

I do not think XDnD is
X11/Unix specific though the name of the protocol is ?Drag-and-Drop
Protocol for the X Window System?. If the MS Windows or Apple OSX
wishes to support XDnD protocol in their file browsers and in other
applications (if not already supported), its a matter of they
generate relevant events as per the XDnD protocol from their file
browsers and other applications. Nowhere in the XDnD protocol
mentioned the protocol is patented. So nothing seems to prevent
anybody implement XDnD protocol.

In my opinion, rather
than we wait until big players implement XDnD protocol, lets offer
X11 guys the XDnD and SDL_DROPFILE for Windows and OSX guys, as XDnD
does not conflict with SDL_DROPFILE. Once big players implements
XDnD, you may deprecate the SDL_DROPFILE.

Kind regards
Sagara


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL can be used well beyond games, into many other applications.

Drag and drop one file, multiple files, and text are very useful.

Drag and drop support in SDL in some form is available to Microsoft Windows and Apple OSX. But the drag and drop support in SDL in any form is not available at all for BSD and Linux users (X11 users).________________________________
From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: SDL Development List
Sent: Tuesday, February 12, 2013 9:22 PM
Subject: Re: [SDL] Patch - Drag and drop using XDND protocol on X11

I assume it can be useful for games that implement their own UI -
especially dropping of text.

2013/2/12, John :

This KIND of thing is of course supported on Windows and Mac (content-type
negotiation between producers and consumers of drag/drop data), and has been
for
a very long time.? So it should be possible for SDL to support a portable
API
for DnD rather than expose X11-specific functionality.

Is DnD useful for games? Would a portable GUI widget framework be more
suitable
for such apps that need DnD, rather than SDL?

On 02/12/2013 12:55 PM, Sik the hedgehog wrote:

I think the point was that SDL_DROPFILE could be compared to
SDL_XDNDDROP (when it involves a file).

2013/2/12, Sagara Wijetunga <@Sagara_Wijetunga>:

Compatibility of “received” data cannot compare to SDL_DROPFILE. In XDnD
data are not received in first place. Data are retrieved at user’s
discretion either at SDL_XDNDPOSITION time or at SDL_XDNDDROP time. If
the
data already retrieved at the SDL_XDNDPOSITION time, you don’t retrieve
again at the SDL_XDNDDROP time.

Whereas, SDL_DROPFILE may be issued once the user released the mouse
button.
In XDnD, user may retrieve data before the mouse button is released.

In SDL_DROPFILE, user receive a file URL and the user has no opportunity
to
specify the type of the data. In XDnD user request the data to be sent
in
the format he wants by specifying the MIME type.

In XDnD user may receive a buffer with one file URL or a buffer with
thousands of file URLs separated by newlines (\n) (or other separator) or
a
buffer with text with newlines (\n).

With “text/uri-list” you know you get a list of file URLs, and with
"text/plain" you know get a story. With other supported MIME types, a
user
can receive data in different formats.

Sagara


? From: Jonathan Dearborn
To: Sagara Wijetunga <@Sagara_Wijetunga>; SDL Development List

Sent: Tuesday, February 12, 2013 1:30 PM
Subject: Re: [SDL] Patch - Drag and drop using XDND protocol on X11

This looks like a good way forward for drag and drop.? We could
genericize
the events a little more (i.e. SDL_DNDENTER, SDL_DNDPOSITION,
SDL_DNDLEAVE)
and only send SDL_DROPFILE (or SDL_DNDDROP) on platforms that don’t
support
such events.? SDL_XDNDPOSITION is used to tell the target window where
the
cursor is because the source window still has focus, right?? How
compatible
is the received data with SDL_DROPFILE?? Is it the important part just a
file URL that is received?

Jonny D

On Tue, Feb 12, 2013 at 5:12 AM, Sagara Wijetunga <@Sagara_Wijetunga> wrote:

We can look at this
problem in few different ways.

First of all,
SDL_DROPFILE and XDnD can co-exists. That is, SDL_DROPFILE can be
used on MS Windows and OSX, and XDnD can be used on X11. The X11 guys
will enjoy a richer functionality :slight_smile:

Second, SDL_DROPFILE
and XDnD are conceptually different. The SDL_DROPFILE is used to
receive a drop event after the mouse button is released, whereas XDnD
is a communication dialogue mechanism comprising series of events,
first receive a notification (XdndEnter) that somebody is trying to
drop something (eg. a single file, collection of files, text, etc.)
before the mouse button is released. This XdndEnter notification
(SDL_XDNDENTER) is sent from a source window (eg. a file browser,
text editor, etc.) to a target window (eg. our SDL application). The
XdndEnter event contain most importantly the data types (represented
in MIME formats) supported by the source window (eg. text/plain,
text/uri-list, etc.). That is, the source can send data in those
formats. Next, the source window sends the XdndPosition
(SDL_XDNDPOSITION) event indicating the position the user trying to
drop. Note, unlike in SDL_DROPFILE, but in XDnD, at this point of
time, before even receive the data, the target window or our SDL
application now has an opportunity to inspect the data types,
position, etc. and decide to accept or reject the drop. At this point
of time, the target window or our SDL application also has an
opportunity to visually indicate whether it is willing to accept or
reject the drop. At the XdndPosition stage, the target application
may retrieve data and inspect to accept or reject the drop before
even user release the mouse button. The target window or our SDL
application can continue the conversation with the source window to
get the data of the drop converted to a suitable format (eg. file
name or file contents, textual or binary data) and finally retrieve
the data and conclude the conversation.

Therefore, SDL_DROPFILE
and XDnD are two different things and SDL_DROPFILE alone is
insufficient to represent the XDnD conversation. Note, it is the
target window or the SDL application decides whether to accept or
reject the drop, not the SDL itself makes this decision.

I do not think XDnD is
X11/Unix specific though the name of the protocol is ?Drag-and-Drop
Protocol for the X Window System?. If the MS Windows or Apple OSX
wishes to support XDnD protocol in their file browsers and in other
applications (if not already supported), its a matter of they
generate relevant events as per the XDnD protocol from their file
browsers and other applications. Nowhere in the XDnD protocol
mentioned the protocol is patented. So nothing seems to prevent
anybody implement XDnD protocol.

In my opinion, rather
than we wait until big players implement XDnD protocol, lets offer
X11 guys the XDnD and SDL_DROPFILE for Windows and OSX guys, as XDnD
does not conflict with SDL_DROPFILE. Once big players implements
XDnD, you may deprecate the SDL_DROPFILE.

Kind regards
Sagara


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Exposing X11-specific functionality could be avoided by dropping the character ‘X’ from functions and events :slight_smile:

Following is the high level picture of the [X]DnD:

(1) dndAware - Assign window property to the created window.

Target ??? ??? ??? Source
------??? ??? ??? ---------

(2)??? ??? <-----??? dndEnter (After Source take ownership of the mouse)

(3)??? ??? <-----??? dndPosition (position of the mouse)

(4) dndStatus ----> (tells the source whether or not it will accept the drop)

(5)??? ??? <-----??? dndLeave (If the mouse leaves the window)

(6)??? ??? <-----??? dndLeave or dndDrop
??? ??? ??? (depending on the “accept” flag in the last dndStatus)

(7) dndFinished??? ---->________________________________
From: John
To: sdl at lists.libsdl.org
Sent: Tuesday, February 12, 2013 9:16 PM
Subject: Re: [SDL] Patch - Drag and drop using XDND protocol on X11

This KIND of thing is of course supported on Windows and Mac (content-type
negotiation between producers and consumers of drag/drop data), and has been for
a very long time.? So it should be possible for SDL to support a portable API
for DnD rather than expose X11-specific functionality.

Is DnD useful for games? Would a portable GUI widget framework be more suitable
for such apps that need DnD, rather than SDL?

On 02/12/2013 12:55 PM, Sik the hedgehog wrote:

I think the point was that SDL_DROPFILE could be compared to
SDL_XDNDDROP (when it involves a file).

2013/2/12, Sagara Wijetunga <@Sagara_Wijetunga>:

Compatibility of “received” data cannot compare to SDL_DROPFILE. In XDnD
data are not received in first place. Data are retrieved at user’s
discretion either at SDL_XDNDPOSITION time or at SDL_XDNDDROP time. If the
data already retrieved at the SDL_XDNDPOSITION time, you don’t retrieve
again at the SDL_XDNDDROP time.

Whereas, SDL_DROPFILE may be issued once the user released the mouse button.
In XDnD, user may retrieve data before the mouse button is released.

In SDL_DROPFILE, user receive a file URL and the user has no opportunity to
specify the type of the data. In XDnD user request the data to be sent in
the format he wants by specifying the MIME type.

In XDnD user may receive a buffer with one file URL or a buffer with
thousands of file URLs separated by newlines (\n) (or other separator) or a
buffer with text with newlines (\n).

With “text/uri-list” you know you get a list of file URLs, and with
"text/plain" you know get a story. With other supported MIME types, a user
can receive data in different formats.

Sagara


? From: Jonathan Dearborn
To: Sagara Wijetunga <@Sagara_Wijetunga>; SDL Development List

Sent: Tuesday, February 12, 2013 1:30 PM
Subject: Re: [SDL] Patch - Drag and drop using XDND protocol on X11

This looks like a good way forward for drag and drop.? We could genericize
the events a little more (i.e. SDL_DNDENTER, SDL_DNDPOSITION, SDL_DNDLEAVE)
and only send SDL_DROPFILE (or SDL_DNDDROP) on platforms that don’t support
such events.? SDL_XDNDPOSITION is used to tell the target window where the
cursor is because the source window still has focus, right?? How compatible
is the received data with SDL_DROPFILE?? Is it the important part just a
file URL that is received?

Jonny D

On Tue, Feb 12, 2013 at 5:12 AM, Sagara Wijetunga <@Sagara_Wijetunga> wrote:

We can look at this
problem in few different ways.

First of all,
SDL_DROPFILE and XDnD can co-exists. That is, SDL_DROPFILE can be
used on MS Windows and OSX, and XDnD can be used on X11. The X11 guys
will enjoy a richer functionality :slight_smile:

Second, SDL_DROPFILE
and XDnD are conceptually different. The SDL_DROPFILE is used to
receive a drop event after the mouse button is released, whereas XDnD
is a communication dialogue mechanism comprising series of events,
first receive a notification (XdndEnter) that somebody is trying to
drop something (eg. a single file, collection of files, text, etc.)
before the mouse button is released. This XdndEnter notification
(SDL_XDNDENTER) is sent from a source window (eg. a file browser,
text editor, etc.) to a target window (eg. our SDL application). The
XdndEnter event contain most importantly the data types (represented
in MIME formats) supported by the source window (eg. text/plain,
text/uri-list, etc.). That is, the source can send data in those
formats. Next, the source window sends the XdndPosition
(SDL_XDNDPOSITION) event indicating the position the user trying to
drop. Note, unlike in SDL_DROPFILE, but in XDnD, at this point of
time, before even receive the data, the target window or our SDL
application now has an opportunity to inspect the data types,
position, etc. and decide to accept or reject the drop. At this point
of time, the target window or our SDL application also has an
opportunity to visually indicate whether it is willing to accept or
reject the drop. At the XdndPosition stage, the target application
may retrieve data and inspect to accept or reject the drop before
even user release the mouse button. The target window or our SDL
application can continue the conversation with the source window to
get the data of the drop converted to a suitable format (eg. file
name or file contents, textual or binary data) and finally retrieve
the data and conclude the conversation.

Therefore, SDL_DROPFILE
and XDnD are two different things and SDL_DROPFILE alone is
insufficient to represent the XDnD conversation. Note, it is the
target window or the SDL application decides whether to accept or
reject the drop, not the SDL itself makes this decision.

I do not think XDnD is
X11/Unix specific though the name of the protocol is ?Drag-and-Drop
Protocol for the X Window System?. If the MS Windows or Apple OSX
wishes to support XDnD protocol in their file browsers and in other
applications (if not already supported), its a matter of they
generate relevant events as per the XDnD protocol from their file
browsers and other applications. Nowhere in the XDnD protocol
mentioned the protocol is patented. So nothing seems to prevent
anybody implement XDnD protocol.

In my opinion, rather
than we wait until big players implement XDnD protocol, lets offer
X11 guys the XDnD and SDL_DROPFILE for Windows and OSX guys, as XDnD
does not conflict with SDL_DROPFILE. Once big players implements
XDnD, you may deprecate the SDL_DROPFILE.

Kind regards
Sagara


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Message-ID: <511AB11E.10702 at leafygreengames.com>
Content-Type: text/plain; charset=windows-1252; format=flowed

This KIND of thing is of course supported on Windows and Mac (content-type
negotiation between producers and consumers of drag/drop data), and has been
for a very long time. So it should be possible for SDL to support a portable
API for DnD rather than expose X11-specific functionality.

Is DnD useful for games? Would a portable GUI widget framework be more
suitable for such apps that need DnD, rather than SDL?

Message-ID:
<CAEyBR+VjsM7-r+2Ce8Mq6CxkbQXK1phteMA5srNU6HSOuUAdrw at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

I assume it can be useful for games that implement their own UI -
especially dropping of text.

Drag and Drop is useful for level-editors, which as far as I’m
concerned should be enough reason for even minimalists to support some
facility in SDL. Though, admittedly, we actually have a minimal
facility at the moment.> Date: Tue, 12 Feb 2013 16:16:14 -0500

From: John
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Patch - Drag and drop using XDND protocol on X11
Date: Tue, 12 Feb 2013 18:22:28 -0300
From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: SDL Development List
Subject: Re: [SDL] Patch - Drag and drop using XDND protocol on X11

Date: Wed, 13 Feb 2013 09:15:53 -0800 (PST)
From: Sagara Wijetunga
To: SDL Development List
Subject: Re: [SDL] Patch - Drag and drop using XDND protocol on X11
Message-ID:
<1360775753.2914.YahooMailNeo at web120704.mail.ne1.yahoo.com>
Content-Type: text/plain; charset=“utf-8”

Exposing X11-specific functionality could be avoided by dropping the character ‘X’ from functions and events :slight_smile:

Following is the high level picture of the [X]DnD:

(1) dndAware - Assign window property to the created window.

Target ??? ??? ??? Source
------??? ??? ??? ---------

(2)??? ??? <-----??? dndEnter (After Source take ownership of the mouse)

(3)??? ??? <-----??? dndPosition (position of the mouse)

(4) dndStatus ----> (tells the source whether or not it will accept the drop)

(5)??? ??? <-----??? dndLeave (If the mouse leaves the window)

(6)??? ??? <-----??? dndLeave or dndDrop
??? ??? ??? (depending on the “accept” flag in the last dndStatus)

(7) dndFinished??? ---->

How about this:

SDL_bool SDL_InteractiveDropAware( SDL_bool );

int SDL_InteractiveDropStatus( SDL_InteractiveDropStatusOptions* );

SDL_InteractiveDropContext* SDL_BeginInteractiveDrop( int /* Pointer
index. / );
int SDL_InteractiveDropAction( ??? );
void SDL_EndInteractiveDrop( SDL_InteractiveDropContext
);

SDL_InteractiveDropEvent -> type ==
( SDL_BEGININTERACTIVEDROP || SDL_ENTERINTERACTIVEDROP )
| SDL_MouseMotionEvent (or other) -> type == SDL_INTERACTIVEDROP_MOVE
| SDL_InteractiveDropStatusEvent -> type == SDL_INTERACTIVEDROP_STATUS
| SDL_???Event -> type == SDL_INTERACTIVEDROP_DROP
SDL_InteractiveDropEvent -> type ==
( SDL_ENDINTERACTIVEDROP || SDL_EXITINTERACTIVEDROP )

typedef struct SDL_InteractiveDropContext
{
int pointer_index;
} SDL_InteractiveDropContext;

typedef struct SDL_InteractiveDropEvent
{
/* Normal SDL event stuff here. */

int pointer_index;
int x, y;

} SDL_InteractiveDropEvent;

typedef struct SDL_InteractiveDropStatusEvent
{
/* Normal SDL event stuff here. */

int pointer_index;
SDL_InteractiveDropStatusOptions *first;

} SDL_InteractiveDropStatusEvent;

typedef struct SDL_InteractiveDropStatusOptions
{
SDL_InteractiveDropStatusOptions *next;

	/* Stuff for the initiator's backend to use. */
SDL_InteractiveDropOptionFlags flags;
size_t optiontext_length; char *optiontext;

	/* Stuff for UIs to use. */
SDL_Surface *option_image;
size_t uitext_length; char *uitext;

} SDL_InteractiveDropStatusOptions;

*Aware is used to enable and disable the “Interactive” (for the
programs involved!) drag’n’drop capability. It could be expressed
through the hints interface.

SDL_Begin* and SDL_End* are used to begin and end an interactive
drag’n’drop situation for a specific pointer, from the INITIATOR’S
end. This would be the stuff that gets used by the folder-viewer
window when you drag a file from it to your map editor window. The map
window would be the receiver (as would any OTHER windows that a
pointer involved in interactive drag’n’drog passed over).
SDL_InteractiveDropContext exists just so that a null pointer can be
returned to indicate failure, it’s contents are just a
demonstration-of-concept and would presumably be different. SDL_Begin*
should also cause the pointer in question to continue sending events
to the initiating window even when outside that window.

SDL_BEGIN* and SDL_END* are the events for the SDL_Begin* and SDL_End*
functions, I just stuck them there because I don’t know if XDnD (or
any equivalents) might need them.

SDL_ENTER* and SDL_EXIT* are the RECEIVING window’s equivalent to
SDL_BEGIN* and SDL_END*. They should be used to indicate when a
pointer currently being used for interactive drag’n’drop “enters” and
"exits" the receiving window’s display area. I don’t think that an
extra “leave” event should be needed (as always, feel free to correct
me).

SDL_INTERACTIVEDROP_MOVE is used to indicate to the receiving window
that an interactive drag’n’drop pointer is moving over it. It should
only be sent between a SDL_ENTER* and SDL_EXIT* pair. Should this be
be provided to the initiating window?

SDL_InteractiveDropStatus( ) and SDL_InteractiveDropStatusOptions are
used by the receiving window to tell the initiating window what
actions it’ll support for the pointer’s current location. The should
only be used between a SDL_ENTER* and SDL_EXIT* pair.
SDL_InteractiveDropStatusOptions should probably have some info on the
window(s) in question, but I don’t have a clue what form that should
take. SDL_InteractiveDropStatusOptions is a linked-list only for
completeness; I don’t know that it would be useful, but it would allow
"ambitious" initiators to provide several options to a user. The text
description and SDL_Surface are for the benefit of the initiating
application, so that it can use them to provide visual (or, with a
screen-reader, possibly audible) feedback on the current option(s).

SDL_InteractiveDropAction( ??? ) is used by the initiating window to
inform the receiving window that an action has been chosen by the
initiating application. It should only be used between a SDL_BEGIN*
and SDL_END* pair. This shouldn’t be guaranteed to invalidate an
interactive drag’n’drop context, but there should be a return value
that indicates that was the result. This should possibly allow for a
specific SDL_InteractiveDropStatusOptions instance to in some way be
used as a reference, but that might not match up well with the actual
platform-specific capabilities.

SDL_INTERACTIVEDROP_DROP is used (along with whichever event
structure) to inform the receiving window of whatever the initiator
gave to SDL_InteractiveDropAction() as an argument. It should only be
issued between a SDL_ENTER* and SDL_EXIT* pair.