Re: Launch Services Issue/Question - two apps using same file extensions
Re: Launch Services Issue/Question - two apps using same file extensions
- Subject: Re: Launch Services Issue/Question - two apps using same file extensions
- From: Dan Korn <email@hidden>
- Date: Tue, 09 Jul 2013 13:25:27 -0700
- Acceptlanguage: en-US
- Thread-topic: Launch Services Issue/Question - two apps using same file extensions
On Jul 5, 2013, at 6:13 PM, Stephen Kay <email@hidden> wrote:
> on 7/5/13 6:38 PM, Quincey Morris at email@hidden
> wrote:
>
>> On Jul 5, 2013, at 14:22 , Stephen Kay <email@hidden> wrote:
>>
>>> It's a shame that there used to be a perfectly workable method for doing
>>> this that no longer works, with no real replacement.
>>
>> If you'll excuse some editorializing, I'd suggest that it was "perfectly
>> workable" only within a pure Mac ecosystem. In the past, there was always a
>> problem trying to preserve the non-HFS metadata when moving files to or
>> through (e.g.) a Windows system. The problem with *that* was the perception
>> that Mac files were "broken" and not safe to interchange. That led to a
>> perception that the Mac was laughable. The current overly-simple way that
>> extensions are used was perhaps a slight over-reaction to this perception, but
>> there we are.
Right. Using Apple-specific resource forks and creator codes was fine back when you were in a Mac-only ecosystem. But it's not just Windows that broke this paradigm. The problem was that this little thing came along call the Internet, and suddenly files were shared between all kinds of systems: Windows, Mac, Unix, iOS, Android, etc. Ostensibly, files on the web should all have MIME types associated with them, but in practice, browsers and operating systems just look at a file's extension to know what it is and how to handle it. FSSpecs were great back in the day too, but when you're connecting to a shared volume, it's the full path that everyone from different operating systems has to agree on, not some numeric volume and directory ID. And we all know that Apple has no problem relentlessly moving forward and leaving older ways of doing things behind.
> Good point, I wasn't thinking about that. But I still wish there was a
> better solution than having 35 file extensions for 7 flavors of the app
> instead of 5 that can be shared between the flavors yet end up with
> different icons...
You could do something like what Windows does when you open a .sln or .vcproj file, when you have multiple versions of Visual Studio installed. Those extensions are associated not with Visual Studio itself, but with a little utility "Version Selector" app, which opens the file, then looks at the contents (the file version in this case), and forwards it along to the appropriate version of Visual Studio. I don't see why you couldn't do something similar with your files, by associating the extension with a similar utility app, although it might make deployment slightly more complicated. (I'll note here that Mac does not have a similar ability in terms of being able to open a .xcodeproj file with the specific version of Xcode used to create it, AFAIK. Although Mac doesn't make it as easy to even have multiple versions of Xcode installed as Windows does with multiple versions of VS.)
I'm not sure about showing different icons on the files based on their contents, although Windows does that too for the .sln files. (I'm don't know exactly what magic makes that work, but maybe, in some ways, the whole Registry thing isn't so bad after all, at least compared to the more inscrutable Launch Services database.)
Dan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden