Unfortunately a printf precision specifier (‘%.*s’) can not come with a width specifier so we have to cast to int. The width specifier ‘t’ is used for ptrdiff_t.
The int → NSInteger change fixed a bug with popup menu positioning, but there was no associated warning or error. It's possible there are more such bugs that we haven't found yet!
As we are no longer using Carbon functions to set menu key equivalents, this means that bundle menu items which have the same key equivalents as main menu items will unfortunately not display their key equivalents in the menu.
There are mainly two reasons for this:
1. Unexplained crashes (see issue #73).
2. We were using lockFocus when getting the symbolic link arrow (from IconRef, as there seems to be no “modern” API to get this arrow) which caused a rasterization of the image.
The new implementation is much simpler, as all work happens in the image representation which does not have any (weak) pointer to its parent image.
There is also a new document_t::encoding_for_save_as_path which returns the encoding that would be used for the document, if saved at the given path. If the document was loaded from disk, it will return the encoding used during load, otherwise it will check tmProperties for which encoding should be used for the path provided. Save dialog for untitled documents will be pre-populated with the result of the above function.
The problem is that when we implement rightMouseDown: then we won’t receive menuForEvent:, but some OakControl subclasses (like OakTabBarView) may want to show a context menu.
A minor caveat is that if there are encoding or newline (folder specific) settings in effect for the chosen path, these trump what’s selected in the save dialog.
If we wish to solve this, the best would be to update the options (shown in the save panel) based on selected folder/filename (and the settings in effect for that).
This closes issue #163.
This was also done prior to commit 806cb44. I just assumed that now that we are back using the system’s named image stuff, we would benefit from their cache, but clearly we are not (especially file browser seemed sluggish because of (re)loading the file type images).
I moved it to a C header. An alternative would be to put some #ifdef’s around the Objective-C stuff in OakAppKit.h, but with the standalone header, it’s clear that this is the only thing we need from OakAppKit.
This code was using (the no longer there in the 10.7 SDK) GetPortBounds() to be able to render into a CGContextRef.
It was also using the private _NSGetCarbonMenu to be able to install the menu handler (that augmented the rendering).
This is using NSAttributedString’s NSTextTableBlocks:
* Font is determined from current menu rather than hardcoded
* Fixed: Invalid font size on bundle-item popup
* Fixed: Both tab triggers and key equivalents can co exists on single menu item
* No relayout calculations are needed after menu update (this is done automatically by NSLayoutManager when using NSTextTables)
* Uses 10.5 compatible API
When the last tab is closed the window will be kept open if the
file browser is shown. It will close the existing document and
replace it with a scratch document.
