This doesn’t do any caching of style lookups so performance is worse than theme_t and it also lacks an API to control the initial base font.
For now, the intention is to use this for system dialogs, such as the Find dialog, but long-term it should also be used by OakTextView, at which point, caching and base font support should be added.
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.
This is the “modern” API that supports multiple items on the clipboard and gives us a badge to show how many items are being dragged.
Though the default drag image does not resemble Finder nor does it seem to support flocking out of the box (where multiple items are collapsed into a single proxy image).
We ship with the “Update Gutter” command enabled by default which is causing a small delay when opening documents because bundle items are currently blocking the main thread.
This commit (together with the previous one) makes it so that we only call it when we have an assumption that it will actually update the gutter.
This is because we may sometimes want to enable implicit animations when updating this property, by making it read-only we limit places from where it can be updated, to make it easier to audit the code.
Currently no-one outside the class actually uses the property, so we could (and may) make it private.
Based on crash reports, some of these functions do fail in practice, mainly due to “too many open file descriptors”, in which case we should let the io::spawn function fail, rather than crash the program.
The io::spawn function is used (amongst others) to update SCM status, so a failure is not always worth notifying the user about (beyond logging an error).
Not sure why the width of this control has been limited as the content of the pop-up is somewhat fixed (unlike e.g. the grammar or symbol pop-ups, which can contain extremely wide entries).
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.
Avoid setting explicit size of the image buttons and do not stretch the buttons to full height, except for reload, as that image seems to use a different size as our other buttons, and therefor doesn’t align properly.
The convenience constructors initializes several additional properties and should be future compatible.
It’s not ideal to have two code paths to construct the UI, but these helper functions should have stabilized by now and will soon be dropped, so this commit also serves to ensure that our UI works with the new convenience constructors.
We generally do want buttons to hug their content, but as long as there is flexible space in the layout, they should act as desired, as the flexible will get the superfluousness width/height.
I checked several dialogs and found none that breaks with this change, presumably it was required for some layout that no longer exists.
Apple has changed the style of borderless controls to use slightly dimmed text color, presumably to use the non-dimmed color when being pressed.
To match this we use the secondaryLabelColor for text, but ideally we should find a solution that does not rely on assumptions about the text color used by the controls.
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.
