You all know the menu bar (or better said NSStatusBar) in Mac OS X.
There are some items which I can move and other which not.
I would like to be able to drag the NSStatusItem of my app.
Any idea how to implement this?
Although NSStatusItems appear near Apple's internal "menu extras", they are distinct and behave differently. It would be nice if Apple unified the items that can appear in the right-hand area of the menu bar, but for now the section is split into distinct "apple internal" (on the right), and "app-provided (NSStatusItem)" on the left.
You can visualize the distinction by putting your computer into screen capture mode (cmd-shift-4), and pressing the space bar to switch to "capture whole window". When you hover over Apple's menu icons, you'll see that they all live in a single window. This explains their ability to be easily managed and dragged about. Hovering over the other items reveals that each NSStatusItem is in fact living in a single window of its own (which happens to be owned by the application that installed it).
It's best to stick with NSStatusItem even though you can't drag them. It's a shortcoming from Apple which most users will understand, even if it's annoying. Emphasizing the positive tradeoffs of offering a more stable application for the long term will usually soften the opinions of your customers (or managers?) who are pushing for the draggability.
You'll have to use NSMenuExtra, not NSStatusItem, and make the menu item a bundle running inside the SystemUIServer process, not your own app. You'll also need code like that supplied by MenuCracker to get this to work.
NSMenuExtra is undocumented and unsupported, and therefore considered a "hack".
My guess for there being two APIs in the first place: a menu extra crashing (or memory leaking) means the entire SystemUIServer process crashing or memory leaking — including other third party modules as well as system-supplied ones. With a status item, on the other hand, such a problem would only affect your own code.
As of macOS Sierra 10.12 http://www.macworld.co.uk/how-to/mac-software/7-sierra-menu-bar-tips-how-use-mac-menu-bar-in-macos-sierra-3649163/
Third-party apps sometimes install as menu extras, have controls that exist in the menu bar, or can be relaunched as faceless apps despite not initially being so. As of macOS Sierra, these menu extras can be rearranged just like native ones. (This wasn't the case through to OS X El Capitan.)
Related
On Mac it is usual that there is a "hidden" main window.
The usual example is "Text Edit". When you open a file you with you don't see a "main frame". Instead every single file will be opened in its own "Text Edit" instance. This is OSX way of emulating the so-called MDI interface.
However, there is an exception. If you open Xcode and open the project there, you can click on the file and it will be open inside the main Xcode window. And if you double click the file it will be opened in its own independent editor window, keeping the main Xcode window visible.
My question would be: do I need to do anything special in order to make my program behave like an Xcode? Should I use different class for the main frame or maybe react differently on the opening document event?
Any hints/pointers where to look or even to the official Apple documentation would be helpful.
The TextEdit behavior you're describing is much more like “SDI” than “MDI”, and the terms “SDI” and “MDI” weren't even needed until Microsoft invented MDI long after Xerox invented the SDI-type interface of which macOS is a derivative.
Anyway, I think you are misunderstanding Xcode's behavior. You seem to think “its own independent editor window” is a different kind of window than “the main Xcode window”. But in fact the new window is of the same kind as the old window, with some optional parts hidden. You can show those hidden parts and make the new window look exactly like the old window. Demo:
The ability to open multiple windows showing the same document (or, in Xcode's case, project) is a matter of software architecture. If you carefully design your app so that multiple windows can share a single model object graph, and can be notified and redraw themselves when the object graph changes, then you have an app that supports multiple windows showing the same document. If you want multiple kinds of windows showing the same document, nothing about Cocoa stands in your way. As a matter of fact, Xcode does have at least one other kind of window in which it shows some properties of a project:
That project settings sheet is really another window; macOS keeps it attached to the main window, but it is in fact an instance of NSWindow (or a subclass of NSWindow), no doubt with its own custom window controller that references the same project objects as the main window.
If you use the Cocoa NSDocument architecture, then a small amount of multi-window support is built-in: an NSDocument knows about its associated windows (via their window controllers). If you want to use the NSDocument architecture, you should read Document-Based App Programming Guide for Mac.
It is unclear what you are after. The traditional Mac UI has been one window per document - i.e. SDI with a single instance of the app running multiple windows - but there has always been the ability for any app to organise the content of that window as it sees fit, including showing multiple "documents" within one window - i.e MDI type UI.
Apps approach such "MDI" in different ways, e.g. some use panes (views) and others tabs. From macOS Sierra the standard NSWindow supports tabs, this system is (semi)automatic for standard document apps. Read Apple's NSWindow Automatic Window Tabbing section in the Sierra release notes for more details.
If you wish to use multiple panes - e.g. like Xcode - you just use views (NSView) and arrange them how you wish.
HTH
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.
For one of my software, I might need to have to add some objects that could have the same behavior as any of object already present (apps/stack etc.), having a contextual menu.
Is it some how possible ?
Thx.
Not possible. That's the domain of applications, files and folders, configured by the user. You do, however, have the ability to add a menu to your own application whose icon appears in the Dock.
You might consider menu extras, but those come with their own set of problems. One in particular is the OS making them disappear when space in the menu bar becomes tight.
I've removed the menu from my cocoa app, all of the interaction should happen from within a status item, that links to a menu, that links to different NSPanels. But this seems to have removed the ability to ⌘C or ⌘V within a NSTextField. Is there a way to add this back without having to have a standard menu included with my app?
Even if your app is a faceless background app, so it never shows a menu bar, you should still have a full main menu because that's what provides all of the default actions (and enables the user to redefine the key commands if they so choose). If you remove the main menu, you have to reimplement everything in it, including anything Apple adds in the future, in code.
And I'd especially warn you against trying to handle keyboard shortcuts yourself. That's damned tricky. A lot of applications get it wrong, causing us Dvorak users (among others) to curse their developers.
I assume you can just implement the actions originally connected to the menu items in a keyDown event. Check out this page for details: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/HandlingKeyEvents/HandlingKeyEvents.html
Just have it respond to cmd-v with paste:, and cmd-C with copy:
Edit: Though I have to agree with Peter, you really should have a main menu...
I'm a Mac user and a Windows user (and once upon a time I used to be an Amiga user). I much prefer the menu-bar-at-the-top-of-the-screen approach that Mac (and Amiga) take (/took), and I'd like to write something for Windows that can provide this functionality (and work with existing applications).
I know this is a little ambitious, especially as it's just an itch-to-scratch type of a project and, thanks to a growing family, I have virtually zero free time. I looked in to this a few years a go and concluded that it was very difficult, but that was before StackOverflow ;)
I presume that I would need to do something like this to achieve the desired outcome:
Create application that will be the custom menu bar that sits on top of all other windows. The custom menus would have to provide all functionality to replace the standard Win32 in-window menus. That's OK, it's just an application that behaves like a menu bar.
It would continuously enumerate windows to find windows that are being created/destroyed. It would enumerate the child windows collection to find the menu bar.
It would build a menu that represents the menu options in the window.
It would hide the menu bar in the window and move all direct child windows up by a corresponding pixel amount. It would shorten the window height too.
It would capture all messages that an application sends to its menu, to adjust the custom menu accordingly.
It would constantly poll for the currently active window, so it can switch menus when necessary.
When a menu hit occurs, it would post a message to the window using the hwnd of the real menu child control.
That's it! Easy, eh? No, probably not.
I would really appreciate any advice from Win32 gurus about where to start, ideas, pitfalls, thoughts on if it's even possible. I'm not a Win32 C++ programmer by day, but I've done a bit in my time and I don't mind digging my way through the MSDN platform SDK docs...
(I also have another idea, to create a taskbar for each screen in a multi-monitor setup and show the active windows for the desktop -- but I think I can do that in managed code and save myself a lot of work).
The real difference between the Mac menu accross the top, and the Windows approach, is not just in the menu :- Its how the menu is used to crack open MDI apps.
In windows, MDI applications - like dev studio and office - have all their document windows hosted inside an application frame window. On the Mac, there are no per-application frame windows, all document windows share the desktop with all other document windows from other applications.
Lacking the ability to do a deep rework of traditional MDI apps to get their document windows out and onto the desktop, an attempt, however noble, to get a desktop menu, seems doomed to be a novelty with no real use or utility.
I am, all things considered, rather depressed by the current state of window managers on both Mac and Windows (and Linux): Things like tabbed paged in browsers are really acts of desperation by application developers who have not been given such things as part of the standard window manager - which is where I believe tabs really belong. Why should notepad++ have a set of tabs, and chrome, and firefox, and internet explorer (yes, I have been known to run all 4), along with dev studios docking view, various paint programs.
Its just a mess of different interpretations of what a modern multi document interface should look like.
The menu bar on a typical window is part of the non-client area of the window. It's drawn when the WndProc gets a WM_NCPAINT message and passes it on to DefWindowProc, which is part of User32.dll - the core window manager code.
Other things that are drawn in the same message? The caption, the window borders, the min/max/close boxes. These are all drawn while processing a single message. So in order to hide the menu for an application, you will have to take over handling of this message, which means changing the behavior of user32.dll. Hiding the menu is going to mean that you become responsible for drawing all of the non-client area.
And the appearance of all of these elements - The caption, the borders, etc. changes with every major version of Windows. So you have to chase that as well.
That's just one of about a dozen insurmountable problems with this idea. Even Microsoft probably couldn't pull this off and they have access to the source code of user32.dll!
It would be a far less difficult job to echo the menu for each application at the top of the screen, and even that is a nearly impossible job. When the menu pops there is lots of interaction with the application during which the menu can be (and often is) changed. It is very common for applications to change the state of menu items just before they are drawn. So you will have to replicate not only the appearance of the menus, but their entire message flow interaction with the application.
What you are trying to do is about a dozen impossible jobs all at once, If you try it, you will probably learn a lot, but you will never get it to work.