I'm writing an application that opens particular kinds of files,
parses them, displays an editable graphical representation of the
contents of a file, and saves the results of the changes to the file.
However, some graphical changes don't result in changes to the
original file, yet those changes need to be saved - a little bit
analogous to the Finder saving the positions of icons in a window, but
not changing the files themselves. This seems like a perfect use of
package documents (a la .rtfd), except for one problem: the files I'm
opening aren't mine, and should remain openable in other applications,
so I can't wrap them up. I'd also really like to avoid making changes
to the files themselves, at least the portions that their normal
programs read.
Through a lot of thought experiments, I've come to the conclusion that
the best place to save this sort of thing would be in the resource
fork of the file being opened, but I could be totally off the mark
there, and it's certainly an unorthodox thing to do.
Anyone have any thoughts on this sort of thing?
-Dan
PS. For reference, the other options I considered while trying to
figure this out:
Option 1. Create a SpotlightStore-like database of all the files I've
opened and their graphical reps. Decidedly suboptimal - it doesn't go
with the files if they move, it may or may not scale well, and it's
vulnerable to someone cleaning out their Application Support folder.
If the user opens a LOT of docs, I don't want this becoming an issue
with Time Machine either.
Option 2. For each file type, figure out if there's a way to write
comments, and put my data there. Actually plausible, at least for the
file types I'll be opening with the initial version... it just
seems... dirty. I hate how CVS does this.
Option 3. Add my own Metadata key and put an XML or similarly textual
version of my graphical rep as the string. I have no idea whether or
not this is possible. It seems like a bad abuse of the metadata system
in any case.
Option 4. Wrap the file anyway and put an alias where it used to be.
Seems like a bad idea. Yes, the target user base for this app would
know what was going on, but it just seems wrong to hide people's stuff
like that.
Option 5. Litter .DS_Store-style files everywhere. Decidedly
unappealing, requiring the file to never move or else lose its
graphical rep.
Daniel DeCovnick
danhd123 at mac dot com
Softyards Software
http://www.softyards.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
