Determining how delivered OSX application is launched?

HI all,

I'm delivering a CAPI application on OS X  (LWM, 6.0), and I want to
be drag files onto the application bundle.  To do this, I provide a
message callback to the application interface that can handle an
:open-file message.  This works without a problem, and my application
can open files as it ought to.

My problem is that I'd like the following behavior:
--- If the application is opened by double clicking the application
bundle, or through Spotlight, &c., I'd like to open an "empty"
document.  To date, I've done this by having my delivery function do
this.
--- If the application is opened by a document file being
double-clicked, or by a document being dragged onto the application
bundle, I'd like to not open the default "empty" document.  At the
moment, the message-callback can handle opening the document, but my
default "empty" document, of course, still appears.

Anyone know how I can detect whether in which way the application was
opened, have a workaround, or know how this ought to be done?  The
desired behavior isn't unusual on OS X—TextEdit, e.g., opens a new
text file by default, but if TextEdit is opened when I double-click a
text file, TextEdit starts and the only open file is the one on which
I double clicked.

I seem to recall using the application's command line arguments a
version or two ago (but I could be mistaken about this), and this
doesn't seem to be a solution now.  (The command line arguments are
the same for both ways of launching the application.)

Thanks in advance,  //JT

-- 
Joshua Taylor, http://www.cs.rpi.edu/~tayloj/

Re: Determining how delivered OSX application is launched?

Josh,

For SANLab I've been just using a flag to determine if the application has received the message callback, and if it has, foregoing the creation of an empty model. This seems to work without any issue.

Evan

On Feb 10, 2010, at 5:46 PM, Joshua TAYLOR wrote:

> 
> HI all,
> 
> I'm delivering a CAPI application on OS X  (LWM, 6.0), and I want to
> be drag files onto the application bundle.  To do this, I provide a
> message callback to the application interface that can handle an
> :open-file message.  This works without a problem, and my application
> can open files as it ought to.
> 
> My problem is that I'd like the following behavior:
> --- If the application is opened by double clicking the application
> bundle, or through Spotlight, &c., I'd like to open an "empty"
> document.  To date, I've done this by having my delivery function do
> this.
> --- If the application is opened by a document file being
> double-clicked, or by a document being dragged onto the application
> bundle, I'd like to not open the default "empty" document.  At the
> moment, the message-callback can handle opening the document, but my
> default "empty" document, of course, still appears.
> 
> Anyone know how I can detect whether in which way the application was
> opened, have a workaround, or know how this ought to be done?  The
> desired behavior isn't unusual on OS X—TextEdit, e.g., opens a new
> text file by default, but if TextEdit is opened when I double-click a
> text file, TextEdit starts and the only open file is the one on which
> I double clicked.
> 
> I seem to recall using the application's command line arguments a
> version or two ago (but I could be mistaken about this), and this
> doesn't seem to be a solution now.  (The command line arguments are
> the same for both ways of launching the application.)
> 
> Thanks in advance,  //JT
> 
> -- 
> Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
> 
> 
> 
> -- 
> BEGIN-ANTISPAM-VOTING-LINKS
> ------------------------------------------------------
> 
> Teach CanIt if this mail (ID 31418092) is spam:
> Spam:        http://respite.rpi.edu/b.php?c=s&i=31418092&m=5709d42b161c
> Not spam:    http://respite.rpi.edu/b.php?c=n&i=31418092&m=5709d42b161c
> Forget vote: http://respite.rpi.edu/b.php?c=f&i=31418092&m=5709d42b161c
> ------------------------------------------------------
> END-ANTISPAM-VOTING-LINKS
> 
>

Re: Determining how delivered OSX application is launched?

If LWM lets you register callbacks for AppleEvents, you should be able
to distinguish the different cases (i.e. in one you'll receive "Open
Application", the other will receive "Open Document") by the events
which are provided by the OS.

See here for AE documentation:
http://developer.apple.com/mac/library/DOCUMENTATION/Cocoa/Conceptual/ScriptableCocoaApplications/SApps_handle_AEs/SAppsHandleAEs.html

I can't check it from here, but the demo cocoa application that comes
with LWM might have the framework you need.

Kev

On Wed, Feb 10, 2010 at 5:17 PM, Joshua TAYLOR <tayloj@cs.rpi.edu> wrote:
>
> On Wed, Feb 10, 2010 at 6:57 PM, Evan Patton <pattoe@rpi.edu> wrote:
>> We do have a splash screen that appears for two seconds at the start of the application, so that may explain the difference in behavior.
>
> Hm… an older version of my app had a splash screen.  In retrospect,
> maybe that's what got things working back then.  It's not a terrible
> workaround, and I'll consider it.  It does feel a bit out of place,
> but it's an option.  (The only OS X applications that come to my mind
> that have splashscreens are cross-platform ones;  e.g., Adobe apps, MS
> Office, and LispWorks.)
>
> OK, one option is a splashscreen;  anyone have anything else?
>
> --
> Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
>
>

Re: Determining how delivered OSX application is launched?

Probably a silly question on my part, but have you checked to see if
the value of 'message' provided to message-callback changes depending
on how the app gets launched?  They might do something simple like
pass nil or :open-file depending on how it started.

Even the existence of that :open-file keyword is neat, because that
probably lets you respond to "Open Document" events, which means that
your app can now be scripted using AppleScript.

Kev

On Wed, Feb 10, 2010 at 8:13 PM, Joshua TAYLOR <tayloj@cs.rpi.edu> wrote:
>
> On Wed, Feb 10, 2010 at 7:17 PM, Joshua TAYLOR <tayloj@cs.rpi.edu> wrote:
>> OK, one option is a splashscreen;  anyone have anything else?
>
> A bit of experimenting, and I've found that the following code gets
> the behavior I'm looking for.  (It doesn't put up a splashscreen, but
> the principle is the same—after a delay, open a blank document if
> nothing's been opened via the message-callback.)  The 0.5 second delay
> seems to be enough to get the message-callback to set the
> file-opened-p slot of the application interface, and isn't too long to
> make the app startup seem sluggish.  I suppose it's possible that I
> could end up with a blank document /and/ the opened one, but I expect
> this is rather unlikely.
>
> (defun start-app ()
>  (let ((app (make-instance 'application)))
>    (capi:set-application-interface app)
>    (capi:convert-to-screen nil)
>    (mp:schedule-timer-relative
>     (mp:make-timer
>      #'(lambda ()
>          (unless (application-file-opened-p app)
>            (app-open-blank-document))))
>     0.5)))
>
> (defun msg-callback (interface message &rest args)
>     (setf (application-file-opened-p interface) t)
>     (app-open-document :pathname (first args)))
>
> I do have one question about this code though.  In start-app there's a
> call, (capi:convert-to-screen nil), and I'm not sure what it's there
> for.  If I omit it, the application terminates almost immediately.  I
> had to run it from the command line to see what was happening:
>
> $ ./MyApp.app/Contents/MacOS/MyApp
> ;; No live processes except internal servers - stopping multiprocessing
>
> The only reason I though to include the call to capi:convert-to-screen
> is that it shows up in one of the example files.  I.e., in
> examples/capi/applications/cocoa-application.lisp
> capi:convert-to-screen is used in the definition
>
> (defun test-cocoa-application-full ()
>  (capi:set-application-interface
>   (make-instance 'cocoa-application-interface-full-test))
>  ;; Start the application with no windows initially.
>  (capi:convert-to-screen nil))
>
> but I'm not clear what it's doing here, or how it "starts the
> application with no windows initially."  Shouldn't the
> capi:set-application-interface have started the application and the
> lack of window-creating-actions left it with no windows initially?
>
> I feel as though my issues with prompts not returning (an earlier
> lisp-hug thread with no responses as of yet) and with this need to
> convert-to-screen may be related, but I'm not quite sure how.
> Thoughts?  //JT
>
> --
> Joshua Taylor, http://www.cs.rpi.edu/~tayloj/
>
>