> On Aug 22, 2018, at 6:56 PM, Rob Petrovec <petr...@mac.com> wrote:
> Carbon also only supported a small set of languages. Cocoa supports 100+
> localizations, including Right-To-Left localizations like Hebrew & Arabic.
> So Cocoa is much more flexible & localizable compared to Carbon.
Not strictly true, although Cocoa does certainly have a wider, better-developed
set of tools for localization (I’m thinking here of automatic tools for finding
string constants in your code and putting them into a .strings file, for
example). But Carbon supports localization to all of the same languages that
Cocoa does. Remember that the Apple menu in every macOS application (Carbon or
Cocoa) is provided by HIToolbox, and the Apple menu is localized to the user’s
preferred system language, so by definition, any language that you can choose
as your primary language for macOS is a language that HIToolbox supports for
localization.
> On Aug 22, 2018, at 5:56 PM, Lars C. Hassing <l...@ccieurope.com> wrote:
>
> The Carbon approach is much better, e.g. to accommodate new application menu
> items from Apple,
> Cocoa developers has to check if a new menubar template has arrived, and
> update their .xib files,
> where Carbon apps would automatically have the new application menu items
> provided by the framework.
I’ll agree with Rob here, “not exactly”.
In the Carbon case, the only menus that would be automatically updated by
Carbon would be the Apple and application menus. All other menus are under app
control, and in general, HIToolbox hasn’t added extra menu items to app-defined
menus, although there are a few rare exceptions.
In the Cocoa case, the application menu is provided directly by the app rather
than AppKit, but in fact there are some cases where AppKit will modify that
menu for existing applications as well; for example, automatically adding “Quit
and Close All Windows” as an alternative to just “Quit”.
AppKit also will automatically add quite a lot of other menu items as necessary
to application menubars, such as Close All, Start Dictation, Emoji & Symbols,
fullscreen-related menu items, Show Next/Previous Tab, and other tab-related
menu items. In general, it is _not_ expected that app developers will rebuild
their menu hierarchy based on a new app template every time that a new version
of Xcode is released. We know that isn’t realistic. Instead, AppKit will
typically automatically insert new standard items as necessary.
In fact, it’s been easier for AppKit to do this than it was to do it in
HIToolbox. Carbon apps often referred to menu items by index, which made it
very hard to insert new items automatically; I built an infrastructure in the
Carbon Menu Manager to allow us to insert new items that didn’t count against
the public MenuItemIndex so that we could add items in a binary-compatible
fashion. In Cocoa, on the other hand, most apps don’t refer to menu items by
menu item index, but rather by tag or item action selector, which are
position-independent. So it’s much easier for AppKit to insert new items into
existing applications without breaking them.
> And all Cocoa developers have to implement CreateStandardWindowMenu and
> updating it themselves ?
The recommended, highly preferred approach is that you build your menu
hierarchy in Interface Builder in Xcode, and include a Windows menu item taken
from the standard object library. That menu item (and its submenu) are
automatically configured to be used by AppKit as the standard Window menu. If
you do that, then you don’t need to do anything else yourself.
If implementing your menu hierarchy in a .xib file simply isn’t possible for
you, then one option to still make use of the built-in support is to get just
your Window menu from the .xib file, but not the rest of the menu hierarchy. To
do this:
- with your .xib file selected in Xcode, in the object library popover, search
for “window menu”. You’ll find one search result, “window menu item”.
- drag that out as a root-level object in your .xib
- connect it to an outlet in your app delegate or some other top-level object
- use code such as this to insert it into the menubar when you are building
your menubar contents:
@interface AppDelegate ()
@property (strong) IBOutlet NSMenuItem *windowMenu;
@end
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
// Insert code here to initialize your application
NSMenu *mainMenu = [NSApp mainMenu];
NSInteger itemCount = mainMenu.itemArray.count;
[mainMenu insertItem:self.windowMenu atIndex:itemCount - 1];
}
That will give you a standard Window menu with all of the standard behaviors.
You could further customize the menu with your own items as you like, either in
the .xib or at runtime.
-eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (Carbon-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/carbon-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
