MAC : Avoid background application in dock Topic is solved

[briceandre]

Dear all,

I have written a multi-platform application that, for some reasons, during execution, starts a new instance of the same application for a background process. This background process does not perform any gui operation.

On Windows, everything works as expected : the background process is launched, performs its computing, and is never displayed to the user.

But on mac, even if the background application is not opening any window, a new icon is present in the dock, and if the user clicks on the icon, an empty menu bar is displayed. Even if it works, this is somehow disturbing for the user.

So, is it possible to programmatically configure a MAC application so that, depending on its arguments, it is displayed or not in the dock ? And if yes, how can this be achieved ?

Thanks in advance,
Brice

PS: using threads for performing background computation in the same process is not an option for my particular problem

[ONEEYEMAN]

Hi,
Check this thread.

Thank you.

[briceandre]

Dear Oneeyeman,

Unfortunately, this will not solve my issue. The same application (and thus, the same bundle) is used for both process. The first process need to be displayed in the dock and needs its own menu, whilst the second process should have none, as it is a background process.

By modifying the info.plist file in the bundle, I will change behaviour for both processes. This is the reason why I am looking for a programmatical mean of changing this behavior in background process.

Regards,
Brice

[ONEEYEMAN]

Hi,
Instead of spawning process can't you create a thread?

Just a suggestion as a workaround...

Thank you.

P.S.: I'm sure there is a solution somewhere, but for now you can try to workaround the issue.

[eranon]

By modifying the info.plist file in the bundle, I will change behaviour for both processes.

Don't know if the Info.plist is read after launch, but if it doesn't have impact on the running process anymore, you could just modify the Info.plist on fly for your new process, then restore it afterward.

And, in case, it's not possible (eg. because the file is locked or subject to be read anytime), you can copy your app bundle towards a temporary directory, then modify its Info.plist and run it from there.

--
EDIT#1: Searching quickly, here is an alternate way (and certainly better -- tested as working): http://codesorcery.net/2008/02/06/featu ... y-to-do-it where you can read:

If you look at the application bundle, it contains another copy of the application within a subfolder of the app bundle itself -- sort of a Russian Doll. But if you look closer, you'll see that all of the components of this "inside" application are actually symbolic links to the parent application's version, except for the Info.plist file. And -- you guessed it -- the internal Info.plist has the LSUIElement set. For the curious, here is a shell script that I came up with to be used as an Xcode build phase to accomplish this.

So, here, not an in-place modification, not a temporary modified copy of the entire bundle, but an embedded lightweight (because of symlinks) copy with a different Info.plist.

--
EDIT#2: And a programmatic way going with Cocoa (but, of course, you have to like -- love would be a little too much -- Objective C): http://www.cocoabuilder.com/archive/coc ... tml#229461. On my part, I would go with the solution in the EDIT #1 above

[briceandre]

ONEEYEMAN: no I cannot use a thread. My previous version of the code used this. But I had a lot of trouble : I launch a JVM with proprietary code running in it (not my code), and it continuously change application settings. In a separate process, it does not bother me, but in the same process, this impacts my own software.

eranon : changing info.plist on the fly seems a little to be a trick. Moreover, it can put the mess in the signature of the bundle, especially if my application crashes before restoring it. The secondary bundle within main bundle with symbolic links could be a solution, but I was not very confident.

I neither like, nor love, objective C, but I followed your last suggestion. I execute the following code at the very beginning of the secondary process and it solved my issue :

Code: Select all

   ProcessSerialNumber psn = { 0, kCurrentProcess };
   TransformProcessType(&psn, kProcessTransformToUIElementApplication);

Thanks to both of you for your suggestions.

Regards,

Brice

[eranon]