3 ms·

Help me understand. Saving yields a psd which indeed requires PS. Whether project lives "inside" app or not it's still bound to it by format, and separate from

by htfu 7y ago

Help me understand. Saving yields a psd which indeed requires PS. Whether project lives "inside" app or not it's still bound to it by format, and separate from your source. So you export the edited version, explicitly overwriting your original. Consumer apps don't care when an "edit" means fresh destructive encoding and overwrite, tools like Photoshop do, but that seems a different discussion. I suppose I'm getting hung up on not at all getting/agreeing with your examples. For "regular" files where that project/"edit in progress" distinction doesn't apply (text/code for example), whether edit-in-place is accomplished through system file manager or back and forth across apps through piping and callbacks is just an implementation and workflow detail. I rarely leave the terminal on my laptop, and prefer my stuff always backed up, so that probably what has me predisposed towards the "traditional" iOS cloud storage and x-callback-url approach to working with files and data across apps and gluing them together. It just mirrors nicely. I get that others have different tastes. But what exactly are yours? Files is confusing because there's also camera roll and the difference between On my device and iCloud isn't clear or something? Same for grandparent, just makes little sense in the context of like, iOS 8, close to none for 13.

TeMPOraL 7y ago
> Saving yields a psd which indeed requires PS. Whether project lives "inside" app or not it's still bound to it by format, and separate from your source. PSD files can be read by other applications. Not perfectly, but can. Many other proprietary formats have been reversed or opened to the point that other applications can read or edit them. And then there's a whole set of formats that aren't tied to any application per se. No app owns JPG, PNG, WAV or CSV. > whether edit-in-place is accomplished through system file manager or back and forth across apps through piping and callbacks is just an implementation and workflow detail. It's not an implementation detail. The "back and forth across apps through piping and callbacks" is under control of the app developers, and the extent to which it works depends on the contractual deals they sign between each other. A file system is an universal intermediary layer owned by no one, which maximizes interoperability and doesn't require the user to maintain or be aware of relationships between app vendors. (Or, look at it from a software design point of view. If you were presented with large and potentially dynamic network of components exchanging data through APIs, you might actually come up with a file system equivalent as a way of separating concerns and maximizing composability.) > the difference between On my device and iCloud isn't clear or something That would be an important difference to have. Basically, "I'm on a train and Internet is spotty, or my ISP has an outage, will I be able to open and work on this file or not?" is a question for which the answer is kind of critical. The Internet is not electricity, it's not always available.
- htfu 7y ago
  Alright, you're talking philosophy and me more about practical usage. But why do you think apps own CSV any more in Files than in Finder? That's where a lot of my confusion stems. Your view of x-callback seems off too, it's a way for apps to expose functionality in a generic way, so the opposite from being dependent on the relationship between any specific app vendors. Since there are many apps that let you glue together stuff yourself (and Apple provides one). > Basically, "I'm on a train and Internet is spotty, or my ISP has an outage, will I be able to open and work on this file or not?" Anything on the local file system is obviously always available. For iCloud there's that status icon I referred to in my first post, but that's no different from desktop.
  - TeMPOraL 7y ago
    > Alright, you're talking philosophy and me more about practical usage. It's very practical. I know we're talking Apple now, but to give an example of a thing that happened to me last week: I couldn't send my wife a PDF with transaction details via e-mail "on the go", from my Android phone, because there was no chain of sharing that would link my bank's app and Fastmail. I could open (not save, just open) a PDF from the bank app, and I could share it, but under sharing there was nothing that would allow me to save it to the filesystem, and Fastmail app didn't show up on the list either. This could be fixed on either app's end, but a better fix would be for the OS to just provide the "Save to filesystem" share target for everything. > Your view of x-callback seems off too Likely - I had very limited experience with iOS (briefly worked with an iPhone that was recent some 3 years ago). It sounds like something similar to Android's intents system. If so, that's a bit better, but if Android's experience is to go by, a lot of linking you'd expect to work doesn't, either because of misconfiguration or purposeful prevention. > Anything on the local file system is obviously always available. For iCloud there's that status icon I referred to in my first post, but that's no different from desktop. Sure, but there are voices calling for making cloud and local completely transparent; I'm strongly against that on the grounds I described.
    - htfu 7y ago
      Wow, peculiar. But ties into my point - there's now "Save to Files" _everywhere_ on iOS (even where it makes little sense) and yeah def a pain when apps that can clearly handle a filetype haven't registered as a target for it. BUT prior workaround was as simple as a basic Workflow share action accepting any input then giving a list of options - Dropbox/Drive, push to desktop over SSH, try "open with" (? can't remember) which for some reason would have a slightly different list of targets... So, file manager is good, obviously, but you weren't crippled before it.

by htfu 7y ago

TeMPOraL 7y ago

> Saving yields a psd which indeed requires PS. Whether project lives "inside" app or not it's still bound to it by format, and separate from your source. PSD files can be read by other applications. Not perfectly, but can. Many other proprietary formats have been reversed or opened to the point that other applications can read or edit them. And then there's a whole set of formats that aren't tied to any application per se. No app owns JPG, PNG, WAV or CSV. > whether edit-in-place is accomplished through system file manager or back and forth across apps through piping and callbacks is just an implementation and workflow detail. It's not an implementation detail. The "back and forth across apps through piping and callbacks" is under control of the app developers, and the extent to which it works depends on the contractual deals they sign between each other. A file system is an universal intermediary layer owned by no one, which maximizes interoperability and doesn't require the user to maintain or be aware of relationships between app vendors. (Or, look at it from a software design point of view. If you were presented with large and potentially dynamic network of components exchanging data through APIs, you might actually come up with a file system equivalent as a way of separating concerns and maximizing composability.) > the difference between On my device and iCloud isn't clear or something That would be an important difference to have. Basically, "I'm on a train and Internet is spotty, or my ISP has an outage, will I be able to open and work on this file or not?" is a question for which the answer is kind of critical. The Internet is not electricity, it's not always available.

htfu 7y ago
Alright, you're talking philosophy and me more about practical usage. But why do you think apps own CSV any more in Files than in Finder? That's where a lot of my confusion stems. Your view of x-callback seems off too, it's a way for apps to expose functionality in a generic way, so the opposite from being dependent on the relationship between any specific app vendors. Since there are many apps that let you glue together stuff yourself (and Apple provides one). > Basically, "I'm on a train and Internet is spotty, or my ISP has an outage, will I be able to open and work on this file or not?" Anything on the local file system is obviously always available. For iCloud there's that status icon I referred to in my first post, but that's no different from desktop.
- TeMPOraL 7y ago
  > Alright, you're talking philosophy and me more about practical usage. It's very practical. I know we're talking Apple now, but to give an example of a thing that happened to me last week: I couldn't send my wife a PDF with transaction details via e-mail "on the go", from my Android phone, because there was no chain of sharing that would link my bank's app and Fastmail. I could open (not save, just open) a PDF from the bank app, and I could share it, but under sharing there was nothing that would allow me to save it to the filesystem, and Fastmail app didn't show up on the list either. This could be fixed on either app's end, but a better fix would be for the OS to just provide the "Save to filesystem" share target for everything. > Your view of x-callback seems off too Likely - I had very limited experience with iOS (briefly worked with an iPhone that was recent some 3 years ago). It sounds like something similar to Android's intents system. If so, that's a bit better, but if Android's experience is to go by, a lot of linking you'd expect to work doesn't, either because of misconfiguration or purposeful prevention. > Anything on the local file system is obviously always available. For iCloud there's that status icon I referred to in my first post, but that's no different from desktop. Sure, but there are voices calling for making cloud and local completely transparent; I'm strongly against that on the grounds I described.
  - htfu 7y ago
    Wow, peculiar. But ties into my point - there's now "Save to Files" _everywhere_ on iOS (even where it makes little sense) and yeah def a pain when apps that can clearly handle a filetype haven't registered as a target for it. BUT prior workaround was as simple as a basic Workflow share action accepting any input then giving a list of options - Dropbox/Drive, push to desktop over SSH, try "open with" (? can't remember) which for some reason would have a slightly different list of targets... So, file manager is good, obviously, but you weren't crippled before it.