Yeah, good point. We could leave saving disabled so that files can't be overwritten in release builds, but that's just postponing an actual transition. For my own URLs, I'd eventually want a one-time conversion that put everything in the new scheme and removed the old fields so they're not plugging up the editor window. For testing, that's probably not cool, since a minor foulup could lead to data loss. I guess the full conversion (i.e. removal) should be a user-invoked action.
We'll have some users who won't want the new data saved in their files, possibly for compatibility with JabRef. That's semi-reasonable, so maybe we can have a default to disable writing those to disk, which means the conversion process happens every time a file is loaded? They lose some functionality, but not all; I'd imagine that script hooks could also be used to copy a BDSKLinkedFile value to Local-Url after autofiling, although I wouldn't advertise that right away. We have to keep the path resolving code anyway for conversion, so we can't rip it out of BibItem. Right now I've been using it with my primary .bib file, which has 1057 pubs, 99 linked files, and 50-100 remote URLs. Opening the file and converting to aliases every time doesn't seem any slower to me. On Tuesday, November 27, 2007, at 03:40PM, "Christiaan Hofman" <[EMAIL PROTECTED]> wrote: >I also think that the next release should be from what is now the >branch, which means that it should be merged. But the problem I see >is that it will be used for the nightly builds from that point on. So >I thin k we first have to make a final solution/decision how we want >to handle the transition from old style file URL fields to the new >files. > >On 28 Nov 2007, at 12:17 AM, Adam R. Maxwell wrote: > >> This is mainly a question for Christiaan, I guess, but what do you >> all think about merging the fileview branch back to the trunk? >> Should we do another release first, or just go for it? I don't >> recall any critical fixes since the last release. >> >> My problem is that I keep going back-and-forth in actual usage; >> today I made a bunch of file content searching changes on the >> branch that probably should have been on the trunk...just because I >> was using the branch at the time. Opinions? There was zero >> feedback on the build that I posted, either because no one tried it >> or everyone hated it. >> >> -- >> adam >> >> ---------------------------------------------------------------------- >> --- >> SF.Net email is sponsored by: The Future of Linux Business White Paper >> from Novell. From the desktop to the data center, Linux is going >> mainstream. Let it simplify your IT future. >> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 >> _______________________________________________ >> Bibdesk-develop mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/bibdesk-develop > > >------------------------------------------------------------------------- >SF.Net email is sponsored by: The Future of Linux Business White Paper >from Novell. From the desktop to the data center, Linux is going >mainstream. Let it simplify your IT future. >http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 >_______________________________________________ >Bibdesk-develop mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/bibdesk-develop > > ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ Bibdesk-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
