3 ms·

Even for a simple text editor, AFAIK you can't continually monitor a directory for changes (FSEvents), so it's hopeless.

derefr 11y ago
How does Xcode work to manage its unadorned project folders, anyway? (I mean, I know it offers you that component that elevates and escapes the sandbox and sprays stuff into /Developer, but Xcode still works if you decline to install that.) Setting Xcode aside, though, the idiomatic "modern OSX" model seems to be one where GUI apps have to own all the files they interact with, usually clumping them together into media-typed document bundle folders. (Xcode's mechanism wouldn't be nearly as inexplicable if the rest of the files lived inside the .xcodeproj.) An idiomatic OSX text editor app would thus, naively, probably have to be quite crippled: the GUI app would have to simply copy your repo into a project document, and make all its edits in there. No ability to watch for git-initiated changes to the source dir or anything. But I think there is still a way to idiomatically support the Unix philosophy of "small components, working together against shared files" in modern OSX. You just can't rely solely on GUI apps to enable it. Instead, you need a separate CLI component that "lives in" the un-sandboxed Unix world to be the manager of the Unix-style integration. Imagine the text editor working on its project bundle, and then a separate CLI component sitting there and just monitoring both the project bundle, and the git working directory—and bidirectionally syncing between them. The sandboxed app still gets to be a sandboxed app, and "works" on its own when the component isn't installed. The component—brought in from outside the MAS, maybe through e.g. Homebrew—just makes extra magic happen. I'm unsure why more MAS apps aren't designed like this, honestly. It's perfectly sensible for Development apps, at the very least; we all install Homebrew anyway.
- anon1385 11y ago
  Xcode doesn't follow the rules that 3rd party apps must follow. It's not possible for a 3rd party to distribute an app like Xcode through the app store.

derefr 11y ago

How does Xcode work to manage its unadorned project folders, anyway? (I mean, I know it offers you that component that elevates and escapes the sandbox and sprays stuff into /Developer, but Xcode still works if you decline to install that.) Setting Xcode aside, though, the idiomatic "modern OSX" model seems to be one where GUI apps have to own all the files they interact with, usually clumping them together into media-typed document bundle folders. (Xcode's mechanism wouldn't be nearly as inexplicable if the rest of the files lived inside the .xcodeproj.) An idiomatic OSX text editor app would thus, naively, probably have to be quite crippled: the GUI app would have to simply copy your repo into a project document, and make all its edits in there. No ability to watch for git-initiated changes to the source dir or anything. But I think there is still a way to idiomatically support the Unix philosophy of "small components, working together against shared files" in modern OSX. You just can't rely solely on GUI apps to enable it. Instead, you need a separate CLI component that "lives in" the un-sandboxed Unix world to be the manager of the Unix-style integration. Imagine the text editor working on its project bundle, and then a separate CLI component sitting there and just monitoring both the project bundle, and the git working directory—and bidirectionally syncing between them. The sandboxed app still gets to be a sandboxed app, and "works" on its own when the component isn't installed. The component—brought in from outside the MAS, maybe through e.g. Homebrew—just makes extra magic happen. I'm unsure why more MAS apps aren't designed like this, honestly. It's perfectly sensible for Development apps, at the very least; we all install Homebrew anyway.

anon1385 11y ago
Xcode doesn't follow the rules that 3rd party apps must follow. It's not possible for a 3rd party to distribute an app like Xcode through the app store.