There is no direct API (as far as I can see) but some applications seem to have it.
Although Apple's own icons (e.g. fast user switching, keyboard layout switching) do not have it.
Since OS X 10.10, NSStatusItem has button property, which is a regular NSView-based control that conforms to NSAccessibility protocol and which allows to change accessibilityTitle property directly.
On earlier versions of OS X, you can implement a custom button that looks and behaves exactly like vanilla NSStatusItem and assign it to the item via -[NSStatusItem setView:] method, then use -[NSView accessibilitySetOverrideValue:... forAttribute:NSAccessibilityTitleAttribute] on your custom control to provide a voiceover title.
Related
I've created an NSStatusItem for my app, but would like it to be navigable, as the system items are, when using Control+F8 (Control+fn+f8).
The status item is inexplicably skipped in the navigation sequence. Is there a secret handshake of accepting first responder or something that needs to be done for this?
This is basically all the setup code I have for the item:
statusItem = NSStatusBar.systemStatusBar().statusItemWithLength(28)
statusItem.menu = menu
statusItem.button?.image = NSImage(named: "menuIcon")
I found a a similar question asked on quoara.com: http://www.quora.com/Why-cant-I-focus-third-party-icons-in-the-status-menu-area-on-OS-X-with-a-keyboard-shortcut-like-Ctrl-F8-SOLVED.
Quoting Colin Barrett:
The third party items are implemented with a different API (NSStatusItem) than the built-in ones (NSMenuExtra). Note that you can drag to re-arrange the menu extras but not the status items (which always appear to the left of menu extras).
Unfortunately NSMenuExtra is private API and with the Mac App Store you're likely to see less and less apps using it.
Just as an example of third party apps which do support this, you can probably F8 to the MenuMeters icon / graph.
So if you really want to make your status menu items available via keyboard you'll have to dig within Apple's private frameworks, however that's an unstable territory, as they're subject to change at any time, without any notification.
As of at least macOS 10.12, it is possible to navigate to an NSStatusItem using the keyboard with Control+F8. This change presumably occurred between OS X 10.10 and macOS 10.12 (I haven’t tested this with any versions earlier than 10.12).
In order to enable keyboard navigation, the NSStatusItem’s menu property must be defined.
The title basically sums up my question. I'd like to know what the difference between the Mac Carbon SelectWindow and ActivateWindow(..., TRUE) is. I've found these in old source and wonder if they are interchangeable (or what their Cocoa equivalents might be).
From memory...
SelectWindow was the response to clicking on a window. It brought the window to the front, activated it, and (usually) made it the first responder. (I'm using Cocoa terminology here.) It's sort of like OrderFront
The SelectWindow function removes highlighting from the previously
active window, brings the specified window to the front, highlights
it, and generates the activate events to deactivate the previously
active window and activate the specified window. If the specified
window is already active, SelectWindow has no effect. Call
SelectWindow when the user presses the mouse button while the cursor
is in the content region of an inactive window.
Activate Window updated the window frame to indicate that the window was the first responder.
You don't really need to know a Cocoa equivalent, you just need to identify what you want to do. Many things from Carbon that required you to implement them are done for you by AppKit. Other paradigms of Carbon APIs just do not happen in Cocoa. They look similar, and had many similar hooks to common OS things, but they're very very different.
Several windows in OS X have drag-and-droppable window icons (e.g. Terminal, Keynote, Finder). Can Qt4 window icons be set up for drag and drop? I can't figure out whether clicking on the window icon triggers any event.
As this feature is specific to only one platform it may not directly available in Qt. Probably you will have to use Cocoa API to handle such events. You can get native window handle:
WId QWidget::winId () const Returns the window system identifier of
the widget.
Portable in principle, but if you use it you are probably about to do
something non-portable. Be careful.
If a widget is non-native (alien) and winId() is invoked on it, that
widget will be provided a native handle.
On Mac OS X, the type returned depends on which framework Qt was
linked against. If Qt is using Carbon, the {WId} is actually an
HIViewRef. If Qt is using Cocoa, {WId} is a pointer to an NSView.
With such handle you probably will be able to handle "window icon drag" with native (not portable!) Mac OS X code
In Mac Lion, the scroll bar hides itself after a few seconds if no activity occurs. I have written an apple script to modify that behavior. I have to turn on the radio button every time my app launches. My question is, I have a cocoa application. Is it possible to keep the scroll enabled for the application always with out having to change the settings in system preferences.I don't want to enable for all the other apps always. And is the only way via the applescript. Or is there a defaults write to enable the scroll bars in lion ?.
I don't know about a defaults key to set up the style.
When you change the Appearance preference panel's "Show scroll bars", all the NSScrollView instances are notified and receive a setScrollerStyle: with the new style (through the NSPreferredScrollerStyleDidChangeNotification notification).
You can achieve the same result by explictly calling setScrollerStyle: on the NSScrollView with the NSScrollerStyleLegacy scroller style.
You can write to defaults to accomplish this.
The key is AppleShowScrollBars and it has three possible values:
Automatic
WhenScrolling
Always
To set it system-wide from the command line, you could do:
defaults write -g AppleShowScrollBars Always
It can also be done programmatically by modifying preferences in any of various ways. It can get a little tricky depending on application sandboxing. This blog post explains it in more detail.
What are the 64-bit replacements for the two methods -[NSMenuItemCell menuView] and -[NSMenuItemCell setMenuView:] of the NSMenuItemCell class?
How can I obtain the same results?
The NSMenuItemCell and NSMenuView have never been used to draw menus in any release version of Mac OS X. The following is an excerpt from the Mac OS X Developer Release Notes:
Notes specific to MacOS X Developer Preview 3
Menu
The implementation of menus has changed drastically; NSMenuView and
NSMenuItemCell are no longer used, -[NSMenu menuRepresentation] now
returns nil, and tear off menus are no longer available. For Developer
Preview 3, there is no support for menu item images. If there is no
text in the menu item, a placeholder text consisting of "< image >" or
"< image name >" will be inserted instead. Menu item state images are
not supported either and in their place the standard checkbox or dash
for on and mixed states are used.
(I'm not sure of the exact timeline of pre-Public beta Mac OS X, but for "Developer Preview 3", I'd guess we're talking around the late 1990s here).
For more info on how menus are currently implemented, see Application Menu and Pop-up List Programming Topics: How Menus Work
As 一二三 alluded to, you use NSMenu along with NSMenuItem to implement menus. In OS X 10.5 and greater, you can use custom NSView instances in NSMenuItems using the -setView: method.
To customise menu item drawing, you need to supply a custom view to NSMenuItem.