We now set the isExpanded property during initialize and use a property to reflect the current user preference for wether or not to collapse when there is just one tab.
We didn’t actually use the file itself, only its parent directory, and there are several places we want SCM info for an untitled file’s project directory, so removing the need for a file simplifies things.
It’s not feasible to maintain the old-style xib translations while we work on the UI. We’ll soon move fully to constraint-based layout which should allow translations to be purely string-based.
With auto-layout the tab bar view can simply invalidate its intrinsic size when it should expand/collapse. This is also done if the global user setting for disabling tab bar collapsing is changed.
On Mountain Lion the OS provides a colorWithCGColor: which tmColorWithCGColor: now wraps for (when available).
This fixes a warning when building with the 10.8 SDK.
We now load the image via NSImage and creates a CGImageRef from that (based on the current graphics context). This ensures we get the @2px version when on a HiDPI display.
__attribute__((format(...))) was added to NSAlert's class-based initializer in 10.7, and due to using string objects instead of literals as informative text, Clang is unable to guarantee the safety of the formatter, and, as such, issues a warning.
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).
