Tim Ekl:
The Core Data setup was fairly straightforward: I wanted Point to store latitude, longitude, and title, so I added two numeric and one string attribute to the Point entity. […] Right off the bat, it seemed like the easiest thing to do was to make the Point
instances themselves conform to MKAnnotation. They already had latitude,
longitude, and title; all that was left was to merge the former into a
coordinate property.
[…]
In testing, though, this soured quickly: a critical operation in everyday use was deleting a Point from the database. However, telling the map view to remove a Point annotation wasn’t quite as prompt as it should have been. Annotations would remain on the map for a few seconds, or in rare cases much longer.
[…]
In the “Discussion” section of the docs for MKAnnotation.coordinate, there
exists this critical qualifier […] As soon as I noticed this, everything clicked: the map was likely using KVO to watch for changes in an annotation’s coordinate, in order to update its location.
Core Data iOS iOS 10 Key-Value Observing (KVO) Mac macOS 10.12 Sierra Map Kit Programming
The Omni Group:
Add a password to your documents to secure them with AES-256 encryption.
Keyboard Shortcuts — Easily customize keyboard shortcuts to your own liking within the app.
[…]
Smarter Paste — To avoid bringing in extra styles when copying data from outside sources, Paste now removes styles but retain links and images. Use the new Paste with Original Style to retain the styles from your source content.
While .ooutline files are zipped by default, package files are still available for scenarios where that makes more sense, like for version control. Note— The previous .oo3 format can still be opened and edited but features requiring the new format will be disabled.
Inspector Sidebar — The inspectors are now contained in a sidebar, allowing you to show or hide them on a per-document basis.
OmniOutliner is one of my favorite apps, and this looks like a great update. I once used it for even more things: task management, bug tracking, time tracking, project planning, recipes, journals, miscellaneous flat lists, etc. Over time, these have migrated to OmniFocus, FogBugz, and RTF/text files in EagleFiler/BBEdit. OmniOutliner is still my first choice for hierarchical or tabular work/notes and checklists. It also works great when preparing my taxes as a middle layer between MoneyWell and TurboTax.
See also: John Gruber, Brent Simmons.
Previously: OmniOutliner Essentials.
Mac Mac App macOS 10.12 Sierra OmniOutliner
user495470 (via Rich Trouton):
- Create a file named
.metadata_never_index inside a folder.
- Rename folders or files so that they end with
.noindex.
- If you only want to hide files from the GUI, move them to a system folder like
~/Library/.
- Move the files to a folder that starts with a period like
~/.fontconfig/. It doesn't remove them from mdfind queries like mdfind 'kMDItemFSName=*' -onlyin ~/.fontconfig/ though.
The .metadata_never_index trick was new to me. Excluding temporary files, or other files that you know you won’t need to search, from Spotlight can really speed things up.
As for Time Machine, I could not find it documented, but it seems to exclude folders with the .nobackup extension. There are also APIs such as CSBackupSetItemExcluded() and NSURLIsExcludedFromBackupKey for excluding items, and you can use tmutil isexcluded to check whether a particular item is excluded.
Update (2017-04-06): Thomas:
I have another one: disable fsevents by creating a “.fseventsd/no_log” file at the root of the volume. Haven’t tested this in a while though.
Mac macOS 10.12 Sierra Spotlight Time Machine
Jesse Squires (tweet):
The proposal SE-0025: Scoped Access Level was reviewed, revised, and finally accepted for Swift 3. This proposal changed the meaning of private to restrict access to an entity to within the current scope or declaration, and preserved the former meaning with a new keyword, fileprivate. The hypothesis at the time was that the new (and somewhat intentionally ugly) fileprivate keyword would rarely be used, thus abiding by Swift’s design philosophy of progressive disclosure. Little did we know that this would not be true in practice.
[…]
After three controversial review periods and revisions, proposal SE-0117: Allow distinguishing between public access and public overridability was accepted for Swift 3. The proposal introduced a new access level called open and changed the definition of public in some contexts.
[…]
Most recently, proposal SE-0159: Fix Private Access Levels was put forward to simply revert the changes of SE-0025. That is, remove fileprivate and restore the original (Swift 1 and 2) semantics of private. […] The new private essentially broke Swift’s extension-oriented style, as private members of a type were no longer accessible from an extension on that type, even if the extension was declared in the same file. The proposal was reviewed with as much controversy and ferver as SE-0025 itself. […] SE-0159 was rejected, leaving the state of access control unaltered.
[…]
The Core Team’s proposal that Doug outlines above is a good compromise. Before I could publish this post, David Hart opened a pull request with a draft proposal titled Type-based Private Access Level for this. I hope it gets accepted and implemented. […] The benefits of a “partly lexical and partly type-based” access control that Doug explains are clear, and I think the outweigh the drawbacks.
Language Design Programming Swift Programming Language
