I create a Mac document based project. After I load a file in a window, I want to clear the content by click the "close" menu item, and not close the window. Then I can load other document in the same window.
You are not very specific so it is difficult to give specific advise.
In general if I were doing this I would redirect the 'Close' and 'Open' menu items in the MainMenu.xib file to my own custom IBAction methods. These custom methods would then alter any data and operate on the window and it's views.
What you are trying to do is counter-intuitive for the user who would expect Close to close the window (possibly asking if they want to save the content first).
I think you just need some sort of Clear action (menu item, toolbar button and key binding) which makes the feature far more obvious and will allow your App to conform to Apple's Human Interface Guidelines.
Related
I have a document-based app, with separate View and Window menus in the main menu. The app uses .xib files, not storyboards.
Trouble is, both menus show duplicate items. I have customized both of them in the Interface Builder. My NSDocument implementation validates needed menu items, but it can't catch the automatically added ones. Even changing the top-menu titles won't affect the default items they are receiving.
Where can I find a setting, which determines which menu will get which items? I've searched intensely and gone through every file in my project, but either can't remember or can't search the correct words to find the solution.
Any help or hints would be appreciated.
Is it possible you originally created the View menu by copying the Window menu? That could explain the duplication. If you control-click the xib in Xcode and select Open As -> Source Code you will see the plist data. Search for systemMenu:
<menu key="submenu" title="Window" systemMenu="window" id="Td7-aD-5lo">
If your View menu has the systemMenu="window" parameter, try deleting it.
I recently updated to Xcode 11 and some of its user interface changed. in older version of Xcode there was options of accessing files in assistant editor using automatic or manual. but in this version of Xcode I can't see any manual option in assistant editor. so I am not able to add IBOutlet and IBAction methods to particular storyboard.
so can anyone tell me how to add these actions and outlets, that would be great help. thanks
By pressing the above button, Xcode will split the view and allow you to select a custom file using the file tree at the top.
You are correct.
The Manual option is no longer visible. You can still achieve the same result by doing a quick open using Cmd+Shift+O then type the name of any file you want to open. Press the Alt key and the file will open in the Assistant Editor Window.
As others have noted the new add editor button allows you to add new editors and open files into them. You could file a bug report but you may want to consider that you're likely to get a "works as designed" type of reply.
You can always change or add new keyboard shortcuts to get the behavior you want by viewing the preferences key bindings area and search for the command you want to shortcut.
Note
You can still ctrl+drag from storyboard to the class by the Adjust
Editor button in the upper right of the storyboard. Then just select
Assistant Editor on the list. After which you can make IBOutlets/IBActions.
open your storyboard, hold option key and select the file you want
In the documentation outline of storyboard, try to choose the "correct" item, which you want to set up outlet connections. Say you want to set up an outlet connection for cell of table/collection view.
View Controller > Collection View > Cell > Content View > Image View.
Try to select Cell, "Content View" or "Image View", then check the jump bar of assistant editor, you're probably able to switch to the .swift file you want.
Reference
In decarbonizing I have now come to creating a menubar programmatically using NSMenu.
Carbon seems to be so nice to add standard items to the application menu: Services, Hide app, Hide Others, Show All, Quit app,
and they are even added using the user’s Preferred Language setting in System Preferences’s Language & Region,
so in German Hide Others is added as Andere ausblenden.
I only had to add the About and Preferences items.
However, it seems that in Cocoa I have to add these standard items myself,
but how can I find out what Hide Others is called in the user’s Preferred Language ?
And what is the Cocoa equivalent of CreateStandardWindowMenu ?
If you have Xcode create a new Cocoa application project, it will make a MainMenu.xib that you can examine. It looks like "Hide Others", "Quit" etc. are just menu items with particular actions assigned, but "Services" seems to have some special magic. Even if you don't want to present a whole menu bar from a nib, you could load it from a nib and then pick out certain menu items and move them to another menu, rename them or whatever. Though I'm not sure I understand what you're trying to accomplish. Even if you don't want to localize, you can use a nib.
To address the last part of your revised question, the NSApplication object has a windowsMenu property, i.e., you could create a menu and say [NSApp setWindowsMenu: myMenu]. But I don't know if that adds items like Bring All to Front or if you must create those yourself.
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.
I'd like to know if it ever makes sense to provide some functionality in a piece of software that is only available to the user through a context (right click) menu. It seems that in most software I've worked with the right click menu is always used as a quick way to get to features that are otherwise available from other buttons or menus.
Below is a screen shot of the UI I'm developing. The tree view on the right shows the user's library of catalogs. Users can create new catalogs, or add and remove existing catalogs to and from their library. Catalogs in their library can then be opened or closed, or set to read-only.
The screen shot shows the context menu I've created for the browser. Some commands can be executed independently from any specific catalog (New, Add). Yet the other commands must be applied to a specifically selected catalog (Close, Open, Remove, ReadOnly, Refresh, Clean UP, Rename).
Currently the "Catalog" menu at the top of the window looks identical to this context menu. Yet I think this may be confusing to the users as the tree view which shows the currently selected catalog may not always be visible. The user may have switched to the Search or Filters tab, or the left pane may be hidden entirely.
However, I'm hesitant to change the UI so that the commands that depends on a specifically selected catalog are only available through the context menu.
The Windows User Experience Interaction Guidelines for Windows 7 and Windows Vista states (pg233):
“Don’t make commands only available through context menus. Like shortcut keys, context menus are alternative means of performing commands and choosing options.”
The Apple Human Interface Guidelines states (pg189):
“Always ensure that contextual menu items are also available as [pulldown] menu commands. A contextual menu is hidden by default and a user might not know it exists, so it should never be the only way to access a command.”
In your case, opening and closing the catalogue appears already available through the +/- buttons in the tree itself, so you’re already consistent with the Windows guidelines, if not the Apple guidelines. IMO, the only reason to put them on the context menu at all is if they're the default (double-click) action (which they're not right now). Rename may also already be available by directly selecting the name of a selected catalog, but you may want a pulldown menu item for that any way since that may be no more discoverable than the context menu. The rest of the commands probably belong on a pulldown menu in addition to the context menu.
As far as the Catalog pulldown menu being redundant with the Catalog context menu, you may want to consider organizing your pulldown menus by type of action, rather than class of object, in order to provide an alternative organization. As you’ve realized, context menus already organize commands by class of object. In addition to providing an alternative organization that some of you users may find more intuitive, this may simplify your menubar. For example, rather than a Catalog and Family menus, you can have a single Edit menu with Add, Delete, Rename, Copy, etc. where these commands apply to whatever is selected, whether it be a catalog, folder, or family. If they don't apply to the current selection, they're disabled, but if it makes any sense in your app, make them apply.
BTW, what’s the difference between Add Catalog and New Catalog?
In general, it's a bad idea to have menu items accessible only through a contextual menu. Many users may not think to right click on an item to find out what actions can be performed on an item.
From your description, it sounds like it would make sense to have a 'Catalog' menu that disables menu options that are not currently relevant. For example, if no catalog is open, the 'Close' menu item would be greyed out. Similarly, the 'Open', 'Remove', 'Refresh', etc. items would be greyed out if no catalog is selected.
I suppose this depends on your user base, and who you're targetting your software at. Personally I wouldn't expect the user to be able to deduce what functionality is available when it is essentially "hidden" until they right-click on the correct item.
If it were me, I'd have a toolbar shown with the functionality exposed on there. By default the buttons would be disabled, and clicking on a node would enable the appropriate buttons based on the context. You could have this in addition to your current right-click options.
As a rule, I've always treated right-click menus as a redundant (i.e not necessary for operation of the software) shortcut to functionality for "power users".
I would leave the menu item out because the user doesn't have a way to see what catalog they are modifying if the treeview is hidden which can create problems if they think a different one is being shown.
Though, the accessible solution would be to trigger it with the keyboard also.
Yes. One key feature of UI is "discoverability": can the user find the function?
If you think that having a top-level menu doesn't make sense, based on the context, then you could have a menu button (scroll down) labelled (e.g.) "Actions" at the top of the pane.