3 ms·

See also the blog post: https://kofi.sexy/blog/multi https://kofi.sexy/blog/multi The swift-only, programmatic approach without Xcode or the typical app framew

by jitl 6y ago

See also the blog post: https://kofi.sexy/blog/multi https://kofi.sexy/blog/multi The swift-only, programmatic approach without Xcode or the typical app framework is very cool! Assembling those parts seems like a great learning experience. (More interesting to me than the actual functionality)

saagarjha 6y ago
A couple of nitpicks about the process: > NSMakeRect/NSMakePoint Generally I prefer the actual constructors. > NSWindow.BackingStoreType.buffered/NSApplication.ActivationPolicy.regular You can just use .buffered/.regular. > let _ = NSApplication.shared Just _ = NSApplication.shared works: https://github.com/saagarjha/DarkNight/blob/0e3aef8559b634cea28c08559d8e338bc21eb419/DarkNight/main.swift#L13 https://github.com/saagarjha/DarkNight/blob/0e3aef8559b634ce... > Rizwan Sattar wrote a neat workaround that monkey-patches NSBundle, which I’ve translated to Swift 4 below Don't do this, it will stop working (crash!) once you update your Swift version and the compiler is smart enough to start making direct calls. As far as I am aware, this is the correct way to do it: https://github.com/saagarjha/DetailsViewer/blob/master/DetailsViewer/Swizzler.swift https://github.com/saagarjha/DetailsViewer/blob/master/Detai...
- hkgumbs 6y ago
  Thanks, these are nice clean ups! I added a note in the blog post that points to your Swizzler example. The final version of Multi didn't end up needing that NSBundle monkey-patch though since it was a "proper app" with an Info.plist file.
  - saagarjha 6y ago
    Yeah, an actual Info.plist is much better :)