I have an app which is run from the menu bar only (LSUIElement is set in the info.plist) which means there is no main menu except the menu I attached to the status item. The problem is I would like to enable some edit commands when using an NSTextView (like command-c to copy) but all command keys seem to be disabled since the app is technically not active (I get beeps when trying any key combinations).
Is there anyway to add a standard edit menu somewhere and enable command keys that would redirect to it? I'm thinking there could be a hack to make the app temporarily active or something but I can't figure anything out.
Thanks.
They're not disabled. They're gone, because you deleted them.
You need to put back your Main Menu.
If you use version control, you may be able to resurrect it from the past using that. If not, you'll have to create a new project, copy anything custom from your Main Menu nib (if you even still have one) into that one, and move that nib into your actual project to be your new Main Menu nib.
The Edit menu commands, window-related commands (e.g., Close), and numerous other commands all live in the Main Menu. If you delete the Main Menu, you don't have those features anymore.
Your Main Menu isn't visible in a UI element app, but that's not a reason to delete it—it's a reason to keep it, even though your app won't have the menu bar, because not being visible means that it won't peek out from behind the curtain but will remain there keeping the magic of your keyboard shortcuts working.
Related
I have created a default [Swift] Cocoa application. I attempted to Ctrl drag from the default Open button in the menu to my View Controller in the assistant editor, but nothing happens.
Is my approach wrong? I assume there is some kind of default file chooser dialog, but I do not know how to make it appear or enable the Open menu item. From the documentation I feel I could make one appear programmatically, but I want to enable the menu button.
My first attempt at an OS X program hit a wall very fast :-/
First, control-Click on Open, and see if it is already attached to a function. If so, click the x to detach it, then try again.
Second, be very sure that the Assistant Editor is presenting the correct file to do the control-Drag. I have found that I need to manually choose the correct file much of the time.
So, after struggling with horrible interface choices of Xcode 4, I'm finally on 5.1.1.
The tabs became almost usable. Double clicking can be configured to open a file in a new tab. Good. Double clicking another file opens it in a new tab. Good. Double clicking first file again switches to previously open tab. Good! Double clicking first file while it is open in current tab opens a second tab with that file. Ok, I can live with that, since from there on they just switch from one to another.
So far a surprisingly sane behavior.
Unless you make a single click in the navigation panel by mistake. Single click opens whatever you click in the current tab, all logic and reason be damned.
The question is, how to change single click behavior to "Use separate tab" (or however Xcode refers to that behavior)?
Is there any way to disable single clicks from doing anything at all aside from highlighting the selection?
There's no option to disable the single-click behavior. Two options that get you close to your desired behavior are:
Use a single separate window for most of your tabs. Use a "main" window that has the file navigator visible, and a separate "work" window with the file navigator hidden. If you want to add a tab to the work window, create it in the main window and then drag it's tab over to the work window. This is an extra step, but you'll never have a single click change any of the tabs that you care about (thought it'll still change the primary or focussed editor in the main window, depending on your settings).
Use separate windows for each file. There's a preference setting that lets you create windows instead of tabs when you double-click a file in the file navigator. Use Mission Control instead of the tab bar to navigate between your files.
In Xcode 4 (4.2), is there a way to keep the Project Navigator view open and Debug Navigator view open as well. Must a user have one or the other, but not both? And the other navigators?
Apple seems to have decided that if you want to see the debug view, you don't want to see the files in your project. WTH? Am I getting this wrong? Did Apple Xcode UI guys even talk to developers before designing the UI for Xcode 4?
Sigh...
You can indeed have more navigators open at once, if you are prepared to have multiple windows open. I know it's not exactly what you're asking for, but for multiple display setups it's very handy. Xcode provides "behaviors" to help automate this process if you only want certain things showing at certain times.
For example, a common pattern that developers follow is to setup a behavior for "Run starts" that opens up a new window setup for debugging. Start by creating a new tab in your main Xcode window by pressing command-T, and double-click on the tab's title to rename is "Debug", or whatever you like. Then drag that window out (or leave it as a tab if you like), and customise the view as required - for example, for a deb window you might have the Debug area showing at the bottom (or even covering the whole editor view), and remove the toolbar at the top by right clicking and selecting "Hide Toolbar".
Next, go to "Xcode > Behaviors > Edit Behaviors..." and choose "Run starts" in the left panel. Check the box for "Show tab" and enter the name of your newly created tab. You can also ask that tab to automatically show the Debug Navigator, and show the debugger with variables and/or console view. If you like, you can then choose "Run completes" and show the original "tab" (window), which I've setup to be called "Coding", and show the required navigator (in my case, Project Navigator).
On successfully running, Xcode will now open up your new window (or bring it to the front if it's already open) with all the settings you left it with. On stopping, your main editor will be brought back to the front.
There are loads of useful behaviors, so I would really recommend looking through them and taking the time to setup Xcode to suit your style as best as possible. All software dictates to the user how to go about doing things, and the developers can never please everybody when they decide to change the UI. The best anybody can hope to achieve is to customise the interface as best as they can to fit their style of working. If it's still an issue for you, you can either adapt to it, or, if possible, move to something else.
I'm not a fan of every new interface feature in Xcode, but I've "made it mine" with some customisations and I can still be very productive. That being said there are a lot of things that I do really like about it, and for that I can forgive it for some of the less friendly features - after all, you can't please every user.
I have a non-document Cocoa application with a menubar icon and status menu. I've added an "Open Recent" menu to the status menu in Interface Builder. Populating the menu works just fine:
[[NSDocumentController sharedDocumentController] noteNewRecentDocumentURL:
[NSURL fileURLWithPath:filename]]
Now I would also like to add a second "Open Recent" menu to a context popup menu. How would I create the menu programmatically so that it gets populated with entries automatically as it does for the version in the status menu?
I tried creating a copy of the one in the status menu, but it does not get populated. I assume that NSDocumentController is not aware of the menu (frankly, I don't know how it knows about the one in the status menu).
For reference, the best documentation on the inner workings of the Open Recent menu that I found is this:
http://lapcatsoftware.com/blog/2007/07/10/working-without-a-nib-part-5-open-recent-menu/
Unfortunately, it doesn’t help much with this, because even if you create the menu like this, it will be ignored by NSDocumentController. The menu must exist in the main menu before applicationDidFinishLaunching: call, otherwise it won’t be picked up — and consequently, duplicate ones are ignored too.
What I ended up doing, and what seems to work so far, is this:
The first idea was to pick the corresponding NSMenu from the main menu and attach it into other menus as well, hoping that reference counting will make this work. No such luck, setSubmenu throws if the submenu is already in another NSMenuItem.
So I “reparent” the submenu instead — when I need to show it in another menu, I remove it from the main menu’s Open Recent item and set it as submenu in the new menu. Later, I move it back. It’s an ugly hack, of course, but it gets the job done.
My application is context-sensisitve and I dynamically build menus for the main window / context/popup, and other places. I typically know if a given menu command will be valid given the current state of the application. Is it better practice to DISABLE/GREY the menu options which currently do not apply OR since I'm generating the menu anyway, OMIT them entirely?
The application is a Java/Swing is anyone is curious. The question seems GUI toolkit agnostic but may be platform dependent.
The old apple guidelines say to Disable for fixed menus (in the menu bar), and omit for context menus.
I guess the motivation is that a context menu is supposed to only show options that are available to the particular context, and the main menus are supposed to show all commands, so the user knows where "Save" would be even if it's not selectable at the moment.
For right-click menus, I'd say that if the item is applicable to what was right-clicked but is for some other outside reason unavailable, disable it. If it is not applicable to the right-clicked thing then hide it as there's no chance of it ever showing up. Case in point:
When I right-click on the background area of this page in Firefox the first four items are Back, Forward, Reload, and Stop. Forward and Stop are disabled because they aren't valid actions right now (I have no forward history and the page is not loading anymore). These four guys are very consistently offered, they are expected, global, often-used commands. They are the four main "navigation" controls and by default they have toolbar counterparts (in the form of big dedicated buttons).
However, if I right-click on an image, I get completely different options in the context-menu all related to viewing, saving, and copying the image under where I clicked. These options don't appear at all (not even disabled) under normal use because they are very specific to what I right-clicked on. When right-clicking on the background area, Stop and Forward, while currently not valid actions, are still applicable to what I clicked on (the page) but they are unavailable for other reasons...
Like the rule for menus on the top menu bar, the goal is not to surprise users with commands suddenly appearing for, from the user's point of view, inexplicable reasons.