On Wednesday, September 12, 2007, at 07:41AM, "Christiaan Hofman" <[EMAIL PROTECTED]> wrote: > >On 12 Sep 2007, at 4:25 PM, Adam R. Maxwell wrote: > >> >> On Sep 12, 2007, at 04:34, Christiaan Hofman wrote: >> >>> BTW, we may have a big change in the way we handle local files in the >>> (near?) future. And I'm not sure if saving relative paths will be >>> compatible with those changes. >> >> I was planning to store a relative path as fallback along with the >> alias for this situation. >> >> Thinking about this again, it may be cleaner to make them relative to >> the home directory instead of the .bib file. Do you recall why they >> are .bib relative now? >> >> adam >> > >So you can easily move the .bib file together with the library of >papers. It makes that the directory structure on the different >systems do not need to be the same, it only matters how the papers >are placed relative to the file. We could also make it relative to >the Papers Folder, but that could break Local-Url fields that expect >it to be different. So I think we never allowed that because of this >backward compatibility. I think if we should allow something relative >to the Home directory we should use ~ instead of a relative path.
Okay, using a document-relative path certainly makes sense in that situation. The question then becomes: should we keep this behavior, or break it now? (By break, I mean use home-relative instead of document-relative paths). Opinions from the users? What's easier for people to deal with? I think Mike may be responsible for the original implementation, so maybe he has comments. I like the ~ path because it gives me a fixed reference frame, and I can move the .bib file without breaking anything else...but since the plan is to use aliases, this problem will go away. In code, I guess the file objects (BDSKFile) could be instantiated by the BibItem with any relative path base as an argument, which would then be used to construct a full path in the case of the alias not working. So there's no argument either way from the code perspective. adam adam ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bibdesk-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-users
