On 28 Nov 2007, at 1:00 AM, Adam R. Maxwell wrote: > 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.
Right, and you couldn't go back to an older version. > I guess the full conversion (i.e. removal) should be a user-invoked > action. > Perhaps an action that first shows a sheet with some options (s.a. whether old fields should be removed). > 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? That's an option. But changes to the files couldn't be reflected in the fields, as there is no link back to originating field. So changes to the file view won't be saved in that case. > 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. > Yes, it's already supported in the branch, as the files are accessible and the there is an autofile script hook. But there are several files and one Local-Url field. > 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. > I've already removed a lot of the methods, there are just a few basic ones left now, at least the most basic one should be left. Alternatively, perhaps the basic resolving method could be moved to an NSString or NSURL category. Christiaan > > 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 >>> Bibdesk-develop@lists.sourceforge.net >>> 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 >> Bibdesk-develop@lists.sourceforge.net >> 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 > Bibdesk-develop@lists.sourceforge.net > 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 Bibdesk-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
