openFile: behavior under Mac OS X

[David_Goehrig]

Hello,

In the src/main/macosx/SDLMain.m, Ryan Gordon had submitted a patch in June
2005, to add NSApplication openFile: support to SDL. In doing so, Ryan
passed a new set of argc, argv to the SDL_main function based on the file
passed through openFile:. The code then ignores all further openFile:
messages after SDL_main has been entered.

My basic question, is would any one be adverse to changing the behavior such
that one could register a callback, or add an SDL_Event type to handle
further openFile: events?

The reason I ask is I’ve recently created a OSX app bundle for SDL Perl, and
as it stands with this behavior, there’s no easy way to force the OS to
spawn another process to run the additional scripts. Every time, one tries
to run two SDL Perl scripts, the second gets caught by the line:

if (gCalledAppMainline) /* app has started, ignore this document. */

return FALSE;

And ends up silently dead in the water. I can think of a few applications
that would benefit from being able to process these sorts of "drag n drop"
events.

Other than this issue, the app bundle is working like a mildly annoying
charm, and once I stopped fighting SDL_main, everything else started working

I’m asking before submitting a patch, because I’m certain someone out there
has to know enough about how Windows handles these events to have 2 cents on
the issue. And I’m pretty certain that this would play into adding Xdnd as
well.

Dave–
“The universal aptitude for ineptitude makes any human accomplishment an
incredible miracle”

-Stapp’s Ironical Paradox

[icculus]

In the src/main/macosx/SDLMain.m, Ryan Gordon had submitted a patch in
June 2005, to add NSApplication openFile: support to SDL. In doing so,
Ryan passed a new set of argc, argv to the SDL_main function based on
the file passed through openFile:. The code then ignores all further
openFile: messages after SDL_main has been entered.

Mostly the goal was to emulate in the Finder what one would do if
running a program from the Unix command line to process a bunch of
documents. In the specific case that prompted the SDL patch, it was so I
could double-click or drag-n-drop downloaded additional levels for some
of Reflexive’s games, which would spawn the game and alert it to install
them before starting. It seemed to me to be the least invasive change
and fairly “Unix-like” in nature, since something launched from the
Finder doesn’t have any command line otherwise (well, not in any
meaningful way, at least).

I don’t necessarily object to adding this as an SDL event, but we only
have room for nine more event types, total, since the events become a
32-bit mask, and bits 25 through 32 are reserved for user-defined
things, off limits to SDL.

There is a “SDL_SYSWMEVENT” type already, which is the “I know what I’m
doing, let me cast this generic pointer to an XEvent, or a Win32 event,
or whatever for my platform”, so perhaps a “SDL_WMEVENT” which can route
cross-platform things like icon drag and drop into the event queue would
be better, since we can reuse the type for other GUI/WindowManager
things. Nothing in this event type would be guaranteed to be implemented
on a given platform (so if there’s no drag and drop on the iPod, it just
won’t ever trigger that event).

The problem is that this quickly becomes “hey can you add an event to
tell me when the clipboard changes” and a million other things that are
in theory “something every platform does” but in practice something only
one app cares about. Lots of bloat and useless effort to try and
castrate system interfaces to make them generalized, albeit never
implemented on most platforms.

Comments and patches are welcome…be prepared for a hearty fight for
either, though.

A better solution for now might be to implement this entirely in the
app, using SDL_SYSWMEVENT, at least as a test case for making it part of
SDL (and failing that, good example code for others). I think
Objective-C lets you do some voodoo to catch messages targetted at other
objects (so you can let SDL handle the drag-n-drops until the app’s
mainline is called, and then handle the rest yourself).

–ryan.

[Bill_Kendrick]

Drag-n-drop might be kind of cool in Tux Paint, both for opening
(importing) images when first loading the app, as well as opening
(importing) images while the app is already running.

;)On Thu, Oct 13, 2005 at 04:57:49AM -0400, Ryan C. Gordon wrote:

Comments and patches are welcome…be prepared for a hearty fight for
either, though.

–
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/

[David_Goehrig]

“A better solution for now might be to implement this entirely in the
app, using SDL_SYSWMEVENT, at least as a test case for making it part of
SDL (and failing that, good example code for others). I think
Objective-C lets you do some voodoo to catch messages targetted at other
objects (so you can let SDL handle the drag-n-drops until the app’s
mainline is called, and then handle the rest yourself).”

Application level voodoo to catch this is too scary to be practical.
Especially since SDLMain is already a delegate of the NSApplication. (ie
we’re already doing this to setup SDL_main()). It would be wiser to
implement register a callback, or induce an event. In any case, since
SDLMain is handling the event right now the correct place is to stick the
event there.

Now it is pretty trivial to add a SDL_SysWMEvent there. However, we still
need to squirrel away, the data associated with this event. Of course,
currently the mac platform has no SDL_SysWMmsg* support requireing we touch
include/sdl_events.h, include/sdl_syswm.h/ and src/video/maccommon/mac_wm*
which are pretty sparse, so we could add a NSString* to a mac specific
SDL_SysWMmsg, just for the openFile: case. But this also feels like a hack,
and doesn’t translate well for adding DND on other platforms.

As for handling other Mac event types, well there really aren’t many others.
There are some Tablet events that I can’t find SDL support for, and there
are all the NSResponder activity for selecting and manipulating buffers. So
in the odd event that we need to add new SDL_SysWMmsg for mac, the choice
here would prejudice the implementation of those. The handling of openFile:
isn’t like the handling of xatoms under X11.

I don’t necessarily object to adding this as an SDL event, but we only

have room for nine more event types, total, since the events become a
32-bit mask, and bits 25 through 32 are reserved for user-defined
things, off limits to SDL.

Well since over half are available I don’t see the problem then
Seriously, I wouldn’t suggest adding a new SDL_Event, unless it would be a
cross platform event. And in this case, I thing it would have to be a
SDL_DND event, which most platforms do have this concept of dropping a file
on an application, or double clicking on a document to load the associated
type.

I’ll do some research into how Windows handles these events before I post a
patch. I simply love the idea of double clicking on a save game to return to
that save point But I think adding a full drag and drop event, would be
worth the effort. (And I’ve wanted it for ages

Comments and patches are welcome…be prepared for a hearty fight for

either, though.

Oh I know damn well that online fights over implementation are nice and
hearty, I have plenty of war stories on that front.

And for sake of argument:

There is another option other than adding an SDL_Event type, we could simply
have a callback that is registered by the user’s application to handle
openFile: requests. This would be similar to using atexit() or the like. The
default behaior here would actually be to fork() and call main() again, with
file as the first argument. There by spawning a new instance of the
application and creating an entirely new NSApplication instance.

By providing the end user with a callback here, you could override this
behavior within your own application, and process the openFile: requests
within the current SDL & NSApplication context. This isn’t a crossplatform
modification, and would only effect how SDL applications work under Mac OS
X. It would help solve the “you can only run one instance” bug, and provide
a means for Mac programmers to respond to openFile: requests.

–
“The universal aptitude for ineptitude makes any human accomplishment an
incredible miracle”

-Stapp’s Ironical ParadoxOn 10/13/05, Ryan C. Gordon wrote: