On 9/12/07, Adam R. Maxwell <[EMAIL PROTECTED]> wrote: > > 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.
Amen for email archives. You asked this same question in December 2005, and apparently 2005 Mike knew more than I do: You wrote: >From looking at the code, it appears that you can also use a .bib file-relative path; I'm not sure why, actually. Offhand it seems that the papers folder would be a better choice for resolving relative paths. The other developers might be able to shed some light on that? I wrote: >Light: someone requested this feature so that they could move bib files and papers around as a single package. For example, you could have this structure: >papers/all.bib >papers/pdf/<*.pdf is here> >then write pdf/p157-fein.pdf in a Local-Url, and if you move your papers directory to a different machine (and different user, location, whatever) you don't have a ton of broken links. >What this means is that any relative path makes it search for the file starting in the same directory as the bib file. I kind of like this scheme (I don't use it, but I apparently thought it was a good enough idea to implement it) but from what I can tell, it's not well known. I have no idea how many people use it. > 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 > -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ------------------------------------------------------------------------- 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
