[Xquartz-dev] LSBackgroundOnly at runtime

[Kyle McKay]

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 at lists.macosforge.org  
wrote:
> From: Jeremy Huddleston <jeremyhu at berkeley.edu>
> Date: December 4, 2007 23:04:27 PST
> To: Developer talk about Xquartz <xquartz-dev at lists.macosforge.org>
> Subject: Re: [Xquartz-dev] LSBackgroundOnly at runtime
> Reply-To: Developer talk about Xquartz <xquartz- 
> dev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20071205/d6060b91/attachment.html