I have a Mono application that should not show on the dock, but will occasionally show a window. I want neither menu bar nor dock icon to show for this application. I have my application wrapped in an app bundle, and my info.plist file has the LSUIElement set to "1". This does not seem to be hiding my application from the Dock.
I have tried also calling osascript with the following info in a Process.Start:
osascript -e 'tell application "System Events" to set visible of process "myapp" to false'
This returns a System Event error code: -10006. Thus far, I've had no luck finding out what that means.
I've also tried all the standard Hide() and Visibility = false stuff inside Mono.
Anyone found a workaround for this, or have an idea a direction I can look in? For the most part, working in Mono has been straightforward .Net coding, but this has me stumped.
Well, after a fair amount of work, I figured out a better way to do this. I am generating a Silverlight + mono application targeting OSX. I needed to get both launching from the same button press.
Solved it with a bash script command from within the bundle that the Silverlight OOB installation process creates, and simply distributed the created bundle, with some rsync commands.
The line that launches the server bit (created using Mono's macpack tool):
open MyApp.app &
The line that then launches the Silverlight OOB app normally:
./Silverlight $# &> /dev/null
The '$#' bit passes all the initial arguments into the Silverlight executable in the OOB app. Means you have to play with the Info.plist to make it launch your own launcher, so your 'Silverlight' executable doesn't get overwritten on a Silverlight update, but seems to work quite well.
This is what you are looking for: http://uselessthingies.wordpress.com/2008/05/18/an-app-without-dock-icon-and-menu-bar/
tl;dr: Package your .app, and in your app's Info.plist add <key>LSUIElement</key><string>1</string>.
Related
I have two application bundles (called ProgramA and ProgramB) that I have written for MacOS. If I use open in Terminal to launch one of them it will launch just fine. But if I try to use open to launch the other one while the first one is open, it will instead bring to the foreground the already launched app. For instance, if ProgramA is already open and I use open -a ProgramB, Program A will instead come to the foreground.
I know I can use open -n -a ProgramB to ensure a new app is launched, but I would like to keep the behavior of bringing the app to the foreground if it already running. If I double-click the icon in Finder the apps will open as expected. The apps are being launched by another app so just using Finder isn't an option.
I thought maybe the issue was a duplicate key in the Info.plist that is used by the system, but that doesn't seem to be an issue. The values for the following keys are unique between the two apps:
CFBundleIdentifier
CFBundleExecutable
CFBundleName
Is there a way I can get open to launch the correct app if other app is already running?
For the next version of a NSDocument-based app, I am revising the document parameters, that is, the values in Info.plist > CFBundleDocumentTypes and UTExportedTypeDeclarations. Specifically, I am changing from a flat NSPersistentDocument to a document package (with the help of BSManagedDocument).
The revised app can create new documents, but they appear in Finder with a generic icon, and when I close such a new document and try to re-open it, -[NSDocumentController openDocumentWithContentsOfURL:display:completionHandler:]fails, creating an error in NSCocoaErrorDomain with code 256, description “newDoc.myExtension” could not be handled because MyApp cannot open files of this type, and failure reason MyApp cannot open files of this type.
I understand that there are several significant parameters CFBundleDocumentTypes and UTExportedTypeDeclarations, and these must all be correct or you get this error. In this case, they are correct. I've confirmed this by comparing the Info.plist in my built product with the Info.plist of a different but similar app that works.
I've also tried calling LSRegisterURL() with inUpdate = true from main(), but that did not help.
What might be wrong? I'm running in macOS 10.12.6, building with macOS 10.13 SDK and Xcode 9.
Apparently the problem is in updating the Launch Services database. I copied the new application, with the revised Info.plist, into /Applications, replacing an old version, then launched this copy once. After these two steps, document icons are now correct when I reopened a Finder window, and upon relaunching my new app, it can now reopen its own new documents without error.
UPDATE: Today (macOS 10.13 Beta 8) I had the same problem, but installing the corrected app into /Applications did not work. However, this time, rebuilding the Launch Services database by running the following command in Terminal, and then relaunching my app, did work:
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -kill -r -domain u -domain s -domain l -v
A side effect of the above is that some apps will have generic icons in the dock and cmd-tab application switcher until relaunched.
I think that either Launch Services much prefers apps in /Applications over apps in Xcode's DerivedData folder, even if the latter is the only one currently running, or running apps from Xcode's DerivedData do not register at all, or both.
It seems from the documentation that calling LSRegisterURL() should have had the same effect, but apparently not.
I am comparing the run of multiple projects using the Xcode simulator. Each time I go to build in one project after having run one of the other projects Xcode tells me that it cannot perform the build and run because the simulator is in use. I then have to find the other project window, stop the run in the simulator (Cmd-.) and then switch back to the previous window and rebuild. Can I make a single keyboard shortcut to stop the current run in the simulator, build and run the current project in the simulator?
There is a little bit of doing involved in making this happen but overall it's pretty easy.
The first thing you'll want to do is open Automator. Incase you've never used it before, it is included on your mac so just search it. When Automator launches, you will be prompted to create a new project, select "Service."
Then adjust the service receives section as follows
On the left side of Automator, you'll see a search pane, search for "Run Applescript" and then drag the instance of "Run Applescript" under your service receives section.
Now you're going to want to change the applescript to suite your needs. In this case you'll replace "(* Your script goes here *)" with "tell application "iPhone Simulator" to quit"
Once you're done altering the Applescript, save the automation as whatever you'd like, it will show up in Services under this name.
Now you're going to head over to "System Preferences" and search "services"
As you can see, I named my Service "Quit Simulator" select yours and define whatever shortcut you want for it. (Try not to conflict with existing shortcuts!)
And now if you encounter the "Simulator in use" error you can quit the simulator, ending any current process with a simple keystroke.
Hope this helps!
Each run is dependent to their project window (as far as I know). So you'll have to go to the project window and stop the build, or simply quit the Simulator (cmd+q) and build again in your new project.
I created a simple testbed app in Delphi XE2, and compiled both a Win32 and OSX version of the application.
I zipped up the OSX version, along with a copy of the libcgunwind dylib runtime file and copied this files to a Mac i have access to.
When I unzipped the file, the mac recognized my OSX application and I double clicked it.
This, in turn, opened up a terminal window for some unknown reason along with my simple app's form.
The application itself ran and behaved just fine, but I'm curious why a terminal window would open up on the Mac?
There is a free tool available for Delphi XE2 that will create the OSX deployment app bundle for you, from Windows, without the need for PAServer.
http://enesce.com/delphiosx_bundler
Check the readme for instructions.
IIRC this happens if you execute the binary directly instead via a bundle
Lazarus/FPC apps had the same problem. IIRC the directly executed binary also didn't get events under those circumstances, but those apps were Carbon based. That problem also went away when running via a bundle setup (which is pretty much a manifest, a few dirs and a symlink)
Your application needs to be run from the application bundle. If you run it directly, you'll get the side effect of seeing the terminal window with the command line that is running the application.
You'll want to read more about Application Bundles.
If you're using PAServer, after you run the program for the first time on the Mac, look in the following folder on the Mac for the application bundle:
/Users/[username]/Applications/Embarcadero/PAServer/scratch-dir/[profilename]
If your project is named Project1, you'll see an application bundle in that folder named Project1.
If you read the above wiki article, you'll know that Project1 has a "hidden" extension of .app, and the whole thing is really a folder with all of the required files to run the application.
To the Mac OS user, the application bundle appears as a single program file, complete with an icon. The user can double-click the application bundle to run the application, drag it to their dock, etc.
The application bundle will have the Delphi icon by default, but you can replace it with your own icon. On the Mac, simply right-click on the application bundle in Finder, and select Show Package Contents. In there, look in the Contents/Resources folder for the .icns file.
Use the Icon Composer application that was installed with XCode to create your .icns icon file from existing image files.
Peek around inside at the rest of the contents. You'll see the required dylib, your program file, and the Info.plist file, which is a text file with things like application IDs, signatures, and other important things.
I create a window in a helper tool that runs in the background (it's not an app bundle with a .nib and Info.plist, but a plain executable). When -makeKeyAndOrderFront: is called, the window is displayed but it does not "pop" out like an active window.
Can this be fixed?
Regards,
Erik
You should wrap the helper tool as a regular .app bundle with at least Info.plist. Then the problem goes away. A GUI app in OS X needs to have an Info.plist to receive events correctly.
The way a GUI app misbehaved if not in an app bundle has never been clear to me. If I remember correctly, it changed over time, depending on OS X's versions. I think it behaved worse in previous versions of OS X. For example, the window is shown but I couldn't click any UI inside it.
Many people who compiled a program in a cross-platform toolkit faced this problem, see e.g. this discussion here in the WxWidgets wiki. Apparently, OS X doesn't mark a program not within an .app bundle as a foreground-able app, which causes your problem. You can use TransformProcessType from your binary not inside an .app bundle to make a foreground-able app to solve your problem, but that's not a documented/intended usage of this function.
So, just wrap it in an .app bundle.
Update:
This "foreground-able-ness" is controlled by the activationPolicy of an app, see this doc on NSApplication. Found the info on this post on Cocoa with love.