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).
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.
Previously we stretched the views to full height (minus bottom divider) and relied on the views to then center their content, but the back/forward images were not properly aligned (at least on 10.14).
At least on 10.14 the window color is neither black (in dark mode) nor white (in light mode) and thus works well to give some contrast to the main text view.
Without this, it would sometimes fail when the outline view had to reload and expand items, presumably because updating the frame of the outline view (after reloading/expanding items) is not “instant”.
This is not relevant for TextMate, but when the file browser is used in other contexts, it would previously show hidden files, as there was no default include pattern to limit files to only those matching `*`.
The purpose was to render text with a shadow and fade the text when the window is inactive, but the former has not been used since 10.10 and the latter doesn’t actually seem to work.
Ideally I would like to have the FileItem class be the public API, as that will then take care of updating the icon’s SCM status etc., current commit is just a temporary fix for missing document icons on 10.14.
When we observe a change on disk we will fetch status after 0.5 seconds if we are active, otherwise 3 seconds.
If we become active and have a pending update, we update immediately.
The reason for the delay is that the change on disk could be the version control system working, for example performing a rebase, and not all systems can gracefully handle requesting status when in the midst of such operation.
Currently SCMManager is not as conservative about refreshing SCM status, specifically SCM status was previously not updated when the application was inactive, the latency for updating was pretty high (3 seconds).
We do however need to check if there are actual changes, as at least in the past, calling `hg` even when there are no changes, may cause file system to be updated, which will trigger a new status refresh.
Originally we had FSEventsManager handle directory loading because it worked as a cache, but it’s better to move this to the client, as not all clients need the directory content, additionally it simplifies the cache invalidation (reload) and also moves the hardcoded list of URL keys to preload into the client, which should know which keys are desired.
