The Find dialog was already using number formatters, but the tool tips shown in the text view (when doing searches or replacements without going through the find dialog) were not.
This makes a difference when the count is > 999, as it will then format the number with thousand separators.
This was unnecessary indirection as we don’t generally lookup strings for the UI (so TextMate is not actually localizable) and the catalog for the strings we did look up was actually out of date.
Since we have multiple application targets, it doesn’t make sense with a global APP_NAME variable.
Though if building the frameworks as standalone bundles and embedding them in different applications, we may need some sort of unique component in the bundle identifier, but we currently do not do this (they are all statically linked, so the Info.plist is currently unused).
This fixes the problem where a folder search has been done and the dialog is later re-opened for another project (which will then take ownership) and then selecting one of the old search results: The “select match” is now sent to the project that was active, when the search was performed.
When requesting clipboard content using stringForType: then NSPasteboard will automatically join all strings using a newline character, so copied results will still paste as a “list” but applications that are aware of multiple pasteboard items could potentially do something different.
The empty status text had a smaller fitting size than when it contained text, causing the UI to resize a few pixels. Fixed by setting the initial value of the button to a space.
The color of the text has been set to controlContentColor which is slightly dimmed (when used in this context), but which caused the text to be highlighted when clicked, even when there was no alternate title. Fixed by always setting the alternate title.
The size of the button is now set to a small button without making any font changes: This means the font is 12 point instead of 11 point, but with the slightly dimmed text color, I think this is appropriate.
This requires clipping the left/right border of the scroll view (using a narrow superview), which is something I have avoided since Interface Builder has a warning about “view is clipping its content” and I seem to recall there being some issues with drawing focus ring around clipped views in the past, but as we are not using a xib nor drawing a focus ring around the NSScrollView being clipped, this approach should be OK.
The advantage is of course that we ensure system colors for the borders.
If creating the checkbox using the NSButton convenience constructor introduced in 10.13 then the existing code had the box sized incorrectly, so this commit is to make the code more robust against a future switch to the convenience constructors.
The NSImageNameRemoveTemplate looks bad in 10.14, and while there is some duplication in this commit, it’s so few lines that sharing this functionality would result in an increase of total number of lines.
Also, switch to use the new divider styles in most places. The remaining usage of the old "OakCreateLine" functions are in the OakChooser windows. These will be refactor for better dark mode support next.
This is in preparation of horizontal scroll: When the table view is horizontally scrollable it is not obvious how we can place a right-aligned button in the group header.
We already auto-hide them for majority of our scrollviews, but since they are hidden by default when using a trackpad, a few “new” scrollviews didn’t get this setting, and I hadn’t noticed.
When all paths had the same prefix as first item, the first item would be returned as the common ancestor even if the other paths were not children.
For example:
/path/to/some_folder
/path/to/some_folder_with_same_prefix
Here `/path/to/some_folder` was returned even though `/path/to` is the common ancestor.
The function is still not correct when all paths are actual descendants of first path, but since it’s only used for display purposes, and with “find in folder” (where paths shouldn’t overlap), I am not bothering with that issue.
We were already using the triangular bullet in a few places, so I made it consistent. Semantically the small triangle might be more appropriate, because we do not use the glyph as a point marker, but I think the triangular bullet aligns better with the text (it’s raised above the baseline where the triangle seems to just touch the baseline).
Currently this bumping is limited to the Find dialog and happens when executing a search. Selecting from the Show Find History or subsequently using ⌘G, does not bump the date of the selected item (but probably should).
There are two issues here, one is that double-clicking a result sends both “selection did change”, “did single click” and “did double click” messages, which all should potentially select the result in the document, but this does introduce a bit of overhead, although I think this is insignificant.
The other issue is that a “single click” or “selection did change” shouldn’t select in the document when the user is selecting multiple items, which is useful for the various Copy actions.
There was a race-condition since we update it in the background queue, where it could be released, and using it in the main queue does not retain it before use.
We were previously assuming that the viewWillMoveToSuperview: was only called when moving to a view and then later when removed, but for 10.8.5 it appears that it might be called multiple times (with a nil superview), causing us to remove ourself as observer from something we didn’t observe.
