On 10/18/07, Adam R. Maxwell <[EMAIL PROTECTED]> wrote:
>
>
> On Thursday, October 18, 2007, at 08:35AM, "Christiaan Hofman" <
> [EMAIL PROTECTED]> wrote:
>
> >> Still don't see how to handle new documents.
>
> I forgot about that until after I sent the message. You previously
> suggested caching the save-destination URL ivar off in BibDocument, and I
> think that would work with a new accessor, as long as we can override a
> point that has the real destination.
>
> >OK, the docs say it can use both relative and absolute paths, you can
> even
> >specify in which order it searches. By default relative first, then
> >absolute, then node ID.
>
> Good...I didn't see that. Interesting that Apple's had relative
> path-based solutions built in to Carbon for all these years, but Cocoa
> mainly requires absolute path/URL.
Well, cocoa also does not support aliases to start with.
>I saw that using FSResolveAlias the alias is automatically updated. When we
> >use (different) relative paths (e.g. for Export) this is unwanted. So
> either
> >we have to make a copy of the alias, or use FSMatchAlias, which is a bit
> >more work. Perhaps we should not keep a BDAlias but an AliasHandle,
> because
> >we need to do some custom things (like this) that BDAlias can not handle.
> >Also when there is no file name we may just use an alias without base
> path.
> >The alias is used basically just for backup, when the FSRef is invalid or
> >null. We may want to update it in some cases though (for a Save As, or
> when
> >creating a new file object, or when copying items between documents).
> >Anyway, I think we just should need a BDSKAliasFile subclass that
> contains
> >an FSRef and an alias for backup.
>
> Yeah, that's roughly the same conclusion I came to when I woke up thinking
> about it this morning :/. I also need to forego all thought of optimization
> while we try to get this working! Maybe even a new (public) class
> altogether, since the current BDSKFile wouldn't be able to figure out which
> class to create? I guess a new initPersistentFileWithPath: or something
> might do as well. We probably don't want to inflict aliases on the orphaned
> file finder.
>
> --
> adam
Another thing, when an item is generated it does not know about its document
(and therefore the base path). So we need to find a way to handle that.
Perhaps the alias should be resolved to an FSRef lazily?
Christiaan
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bibdesk-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
