Re: Filing of User Presets - files vs. builtin
Re: Filing of User Presets - files vs. builtin
- Subject: Re: Filing of User Presets - files vs. builtin
- From: Robert Grant <email@hidden>
- Date: Fri, 25 Oct 2002 16:39:14 -0400
On Friday, October 25, 2002, at 04:07 PM, Kurt Revis wrote:
On Friday, October 25, 2002, at 12:45 PM, email@hidden
wrote:
Using .plist is a standard file extension and would therefore be more
preferable to me. Plus, it would be easily openable in Property List
Editor which would be great for development. Plus, if it is a plist,
why not show it in the extension, that's what it's for ;)
I haven't really been following this discussion closely, but this
seems like a really bad idea. .plist is TOO general. It's already in
use in a number of completely different contexts (in the persistent
storage for CFPreferences, and inside app and bundle wrappers, just
for starters). There are already more than 5000 .plist files on my
machine, and none of them are AU presets.
You're not saying that the insides of the file should not be plist?
Just that the extension
should be changed?
A specialized extension would also allow icons to be assigned to
preset files, and for the usual linking of files to applications to
happen.
Also, in Open dialogs, it's much easier and MUCH faster to filter by
file type/extension than to open and read every single file in a
directory.
The problem is that even though they're all preset files they're not
usable with any
AU. So even if they had the extension "aupreset" or something we'd
still have to
crack open the files to see if they match. Surely you're not proposing
a separate
extension for each AU?
I've found the delegate function that NSSavePanel uses to validate
inclusion in the
display and I'm investigating how well it'll handle this particular
task.
Robert.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.