Re: [Xquartz-dev] LSBackgroundOnly at runtime
Jeremy, I was going to post the below suggestion, but someone beat me to it. I have been playing around with a simple test application and that does exactly this. It uses this key in the Info.plist <key>LSBackgroundOnly</key> <string>1</string> Which is not exactly the same, but I expect <true/> to be just as good. Then it does exactly what your code below does and a Dock icon always appears after calling TransformProcessType. If I comment out the TransformProcessType call there's no Dock icon. Are you calling TransformProcessType as early as possible? Also keep in mind that when you're started by the finder, you'll get this extra argument that starts with -psn_. But it seems like you could call TransformProcessType immediately in main if argc<=1 or argc==2 and argv[1] starts with "-psn_" or maybe I have the sense of that test backwards, but you get the idea about the extra argument you have to account for. Kyle On Dec 5, 2007, at 05:00, xquartz-dev-request@lists.macosforge.org wrote:
From: Jeremy Huddleston <jeremyhu@berkeley.edu> Date: December 4, 2007 23:04:27 PST To: Developer talk about Xquartz <xquartz-dev@lists.macosforge.org> Subject: Re: [Xquartz-dev] LSBackgroundOnly at runtime Reply-To: Developer talk about Xquartz <xquartz- dev@lists.macosforge.org>
Hrm... I tried this (needs to be in a separate C file due to type conflicts):
#include <ApplicationServices/ApplicationServices.h>
int moveToForeground() { ProcessSerialNumber psn = { 0, kCurrentProcess }; OSStatus returnCode = TransformProcessType(& psn, kProcessTransformToForegroundApplication); if( returnCode == 0) { //SetFrontProcess(&psn); } return (int)returnCode; }
and called moveToForeground() before server_main(). this was added to Info.plist: <key>LSBackgroundOnly</key> <true/>
returnCode was 0 (success), but the app didn't show up in the dock. I'm thinking this just won't work and I'm willing to settle with the current situation for now (since it's still better than before)... but still not optimal...
--Jeremy
On Dec 5, 2007, at 09:12, Kyle McKay wrote:
I was going to post the below suggestion, but someone beat me to it. I have been playing around with a simple test application and that does exactly this.
Would you mind sending me your test application's source?
Are you calling TransformProcessType as early as possible?
Yes, in main(), I just decide whether to do the launcher or the server, and I call the TransformProcessType right before I call server_main().
Also keep in mind that when you're started by the finder,
We're not. We're started by launchd in the case where we make these calls (argv[1] is "--launchd" to tell me this).
you'll get this extra argument that starts with -psn_. But it seems like you could call TransformProcessType immediately in main if argc<=1 or argc==2 and argv[1] starts with "-psn_" or maybe I have the sense of that test backwards, but you get the idea about the extra argument you have to account for.
Does your application work if executed from the Terminal? (ala TestApp.app/Contents/MacOS/TestApp)? Thanks for the help, Jeremy
On Wed, Dec 05, 2007 at 09:12:04AM -0800, Kyle McKay wrote:
Are you calling TransformProcessType as early as possible? Also keep in mind that when you're started by the finder, you'll get this extra argument that starts with -psn_. But it seems like you could call TransformProcessType immediately in main if argc<=1 or argc==2 and argv[1] starts with "-psn_" or maybe I have the sense of that test backwards, but you get the idea about the extra argument you have to account for.
Actually - just what does '-psn_' imply? Given that it is passed when started by launch services, I was assuming it meant the 'TransformProcessType' has already been called by the process before the exec(2) was called to start the application. i.e. that the app is being informed about the PSN which has already created. This would seem to fit with keyboard events being available for an program run from the cli which then uses TransformProcessType (i.e. not in a bundle, and not started by 'open -a'). DF
On Dec 5, 2007, at 15:14, Derek Fawcus wrote:
Actually - just what does '-psn_' imply?
It is passing in the process serial number on the command line AFAICT.
Given that it is passed when started by launch services, I was assuming it meant the 'TransformProcessType' has already been called by the process before the exec(2) was called to start the application.
I don't think it transforms the process type so much as it starts thay way by looking at the plist.
i.e. that the app is being informed about the PSN which has already created.
I think you're confused here (or maybe I am). Each process has a psn associated with it which is analogous to a unix pid (and you can map between the two). So the process knows its psn, and LaunchServices just makes it easier to get the info by passing it on the command line as well.
This would seem to fit with keyboard events being available for an program run from the cli which then uses TransformProcessType (i.e. not in a bundle, and not started by 'open -a').
Actually, I don't think it has to do with it being a bundle versus not. I think it has to do with being a foreground versus a background application. --Jeremy
On Wed, Dec 05, 2007 at 05:45:25PM -0800, Jeremy Huddleston wrote:
On Dec 5, 2007, at 15:14, Derek Fawcus wrote:
Actually - just what does '-psn_' imply?
It is passing in the process serial number on the command line AFAICT.
My question was more of a 'why' than a 'what'.
I think you're confused here
quite possibly.
(or maybe I am). Each process has a psn associated with it which is analogous to a unix pid (and you can map between the two). So the process knows its psn, and LaunchServices just makes it easier to get the info by passing it on the command line as well.
Your statement implies a static mapping (which may well be the case). I had been assuming it was a dynamic mapping - a PSN not being associated with a pid until one is requested.
This would seem to fit with keyboard events being available for an program run from the cli which then uses TransformProcessType (i.e. not in a bundle, and not started by 'open -a').
Actually, I don't think it has to do with it being a bundle versus not. I think it has to do with being a foreground versus a background application.
That is what I tried to express - the transform allows it to get keyboard events. Normally an unbundled program will not be a foreground task, and so cannot get such events. DF
participants (3)
-
Derek Fawcus
-
Jeremy Huddleston
-
Kyle McKay