I am developing an OS X app
That uses StatusBar and Also has Windows
I would to move my app to "background" (That only StatusBar will be shown and windows ofc and not applications main menu)
When all it's windows are closed.
(I want to do it so, the app won't appear in cmd+tab menu etc, I want only StatusBar to be).
I am quite don't know where in documents to look for it and if it is even possible.
I have found that in Info.Plist I can put a flag to enable "LSBackgroundOnly" - then I see only my StatusBar.
But I want to switch between background and foreground, Since I want to allow my user to open the main Application Window via the StatusBar menu as well.
What would be the best approach or where to look for this ?
Sorry to flag as a possible duplicate. The other question doesn't exactly have good keywords for searching, but the answer is the same:
Use or modify the code in the answer here.
The info.plist settings are or OSX versions before 10.9 and cannot be changed at runtime. 10.9+ you can use NSApplication's setActivationPolicy and application delegate functions to do what you want. See discussion here and here as well.
Related
My OSX app lives entirely in the menu bar, and thus does not have a conventional "main window" with a close button nor a standard system menu. The app was rejected due to lack of compliance with the HIG: "we have found there is no way to quit the app." Of course, the Cntrl+Q hotkey works, but that's besides the point. To clarify, here's what my app looks like: http://airgif.com/images/mordor.png
The question is: what is the preferred method for implementing a quit button in a menu-bar app? Is it sufficient to simply have a NSButton with the title of "quit app" somewhere within the app's settings?
The usual approach is just to have a quit command at the bottom of the menu.
From the Beginning of Time, Apple has enforced the Human Interface Guidelines.
A way for the user to quit the app is required.
After all, we don’t want OSX to look like some webpages with popups you can’t get rid of.
I'm working on wrapping some Cocoa functionality in an Objective-C library that will be called from a cross-platform C library. One of my goals is to provide someone who does development in C on Linux with the ability to deploy to OSX without having to get into XCode, nib files, etc. I want them to be able to compile and link their code on OSX using the command line tools, and end up with a regular resizeable main window with the usual buttons and so on, an application menu and a dock icon that looks and behaves as expected, etc.
I'm working on OSX 10.8.5. I have XCode 5.0 installed. Here's my gcc --version output:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.76) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
I've figured out how to present a main window, how to set up the application menu, and various other things, programmatically, without using XCode or any nib or plist, but I've run into a problem with the dock icon.
I set a custom dock icon image by calling:
[NSApp setApplicationIconImage:dockImage];
When the user quits the app, the dock icon image reverts to something else (some kind of default application icon or view), briefly, before going away. How can I prevent that from happening without using XCode to create a nib or a plist?
I've tried setting the activation policy of NSApp to prohibitted in the app delegate's applicationShouldTerminate method, to try to hide the dock icon before this switch back occurs. That didn't help, it does hide the window and the dock icon, but the dock icon still switches back to the default icon, briefly, as part of the process of hiding. I confirmed this by returning NSTerminateLator, and confirming that setting the activation policy to prohibited does cause the dock and the icon to hide even though the app is not terminating, and not setting it leaves it unhidden.
I've tried subclassing NSApplication and overriding the setApplicationIconImage call. I have confirmed that it is being called a second time, by something other than my code (well, or not directly by my code, anyway), just before the program exits. I've tried preventing the second call to it from working by calling the super function the first time, but not the second time, and I've confirmed that code in that function can prevent my code from changing the application icon, but that didn't fix the problem. It still happens anyway, somehow.
I've also tried removing the application badge, like this:
[[window dockTile] setShowsApplicationBadge: NO];
just in case it was something to do with that, but that didn't work. The docs say that app badges are no longer relevant as of 10.6, but I was grasping at straws.
Being stumped on the programmatic front, I'm now trying to find out how to package an .app from scratch,without using XCode, and see if maybe I can create a plist from scratch that has a reference to application image in it. But a programmatic solution would be preferable, as I'd really like to minimize what goes into the OSX-specific packaging of a deployment.
Another possibility might be to use XCode once, to produce a very generic, bare-bones .app that my deployment scripts copy and alter.
Please don't shoot my question down as being "too broad" or "not constructive" or something like that. I realize I'm reinventing wheels that already exist in various forms, but there's no law against trying to build a better mouse trap, or just a different or even a worse one, for that matter. I realize I'm trying to fix a problem that a lot of people would consider inconsequential, but XCode-produced apps don't have this problem, and I really don't want the tools I'm creating to produce any user-visible artifacts like that. I'm not intending to diss Apple's tool chain or invite debate about whether or not what I'm pursuing should be pursued. I have a specific, technical problem that I'm looking for solution to that is within the constraints of my goals.
With windows 8, is it possible to create an application that is always visible? For instance, in previous versions of windows, there is the task bar with quick launch icons. Can I create something similar to the quick launch icons that are always on the screen?
If you are referring to a Windows 8 Store app then the answer is no. You can have a live tile and toast notifications that provides updates to the user which may cause the user to launch your application.
A good article to read to understand how your Windows Store apps will run on Windows 8 go here to learn about Application lifecycle (Windows Store apps). This will explain the App execution state.
It is not possible in the RT version, but the same is possible in the desktop version. If you have a desktop app, you can pin it to the taskbar. But any Window store app cannot be pinned to the taskbar. What you can do instead is move the app to the beginning of your Home screen, so anytime you click the Windows button your app will be visible right in front.
Do you mean always visible in the Star Menu screen? If so, you can add tile updating functionality to your application. As long as the user has the application pinned to the Start Menu, he would see the updates. Check the link below for an introductory tutorial.
http://blogs.msdn.com/b/windowsappdev/archive/2012/04/16/creating-a-great-tile-experience-part-1.aspx
"Quick Launch" has a very specific meaning, which you may or may not have been referring to in your question.
Below is the Quick Launch bar in Windows 8 - essentially a toolbar pointing to a location in your %AppData% directory. Prior to Windows 7 it was available by default, but the ability to now pin items directly to the taskbar rather supersedes it. Here's how you can restore Quick Launch if you really want to :)
It's, of course, available only in the Desktop mode and not on the Modern UI, where pinning a tile is the best you can hope for, and it's all up to the user to pin it AND to determine where it shows up on their Start Screen.
Another option worth mentioning (although more like system tray than quick launch) is lock screen presence. If the user chooses so and your app supports that, he can add it to his lock screen:
either as a a badge (up to 7 apps)
or as a tile notification (single app only)
This is not a way for the user to quickly start your app (other answers have already covered these options) but a way to stay visible and keep your user informed.
I am writing Contextual Menu Plugins for Leopard OS and referring Writing Contextual Menu Plugins for OS X, part 1 article by Brent Simmons. My plugin is working fine.
Is there any way to move my test menu into main menu (above the Label)?
The short answer is "no".
The OS controls what gets displayed in that menu, so in order to change it around, you would need to call private methods, reimplement system-level functionality, and just in general do some Very Bad Things which would be unsafe, could break at a moment's notice, and possibly work differently between even dot releases of the same OS.
Yes, it's called a system service, and was introduced in OS X 10.5. I know for a fact that many applications can do this, and Automator routines can be triggered this way because Automator itself is a system service. To see a service applicable for an application (i.e. Finder) go to the Application menu on the top bar (for lack of better name T_T), such as the Finder bolded text, and go down to Services > and it will show you all services that can be used in the app. If you need pointers on how to build this, just comment here.
EDIT: Yes, a SIMBL plugin is also considered a service, and on second read of your question, that's what you want.
I am a newbie in Mac application development. I want to write a GUI application in Cocoa using Interface Builder. I want multiple screens i.e. when one button on a screen is clicked, another screen should be displayed. How can I activate a new screen at button click event?
I would heartily recommend Aaron Hilegass's book Cocoa Programming for Mac OS X. It took me from feeling like everything was impossible to being relatively competent in the space of a few short weeks. I was very impressed with it.
Apple's documentation is amazingly good, but it takes a while to get used to the style, and you will need to know which objects actually exist before you can look up how to use them, which is where Aaron's book comes in.
Your library may have a copy of it, or be able to order one for you if they don't.
I think you mean windows, not screens. Screens are the displays (monitors) on which all the user's windows from all the user's applications appear.
And I second Jonathan's recommendation of the Hillegass book.
The button has a target. That should link to the new window. As its action you can tell the window to show itself.
Take a look at:
http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/WinPanel/WinPanel.html
I think what you want is the type of interface like that seen in Coda, or System Preferences where there is a toolbar on the top of the screen that can be used to select between the content of the window.
The simplest method I have found is to use BWToolkit.
Another method is to use a series of views, and switch between them when the toolbar is clicked. I've found one description here, but that's not the one I used first (which may have been originally in Ruby Cocoa, IIRC).
NSTabView.