On 28 Nov 2007, at 2:37 AM, Adam R. Maxwell wrote: > > On Tuesday, November 27, 2007, at 04:21PM, "Christiaan Hofman" > <[EMAIL PROTECTED]> wrote: >> >> 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. > > Thanks for the reminder to commit my bib file :). > >>> 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). > > Yes, that sounds reasonable. Having an action also means that we > don't have to check each document as it's opened to see if it's > been upgraded or not. >
But would the action be the only way to upgrade, or would there be an automatic way? It won't be obvious for the users to go look for this 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? >> >> 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. > > You mean moving files in Finder would break things just as they do > now? Oh, rearranging or deleting wouldn't work...yeah, that would > be a little weird, but at least it would be nondestructive. And adding/deleting files in the fileview. > >>> 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. > > Cool, that should give power users enough rope to hang themselves; > they could probably create new fields if needed or something if > Local-Url isn't empty. > I was also thinking we may want to change the script hook for autofile a bit. Right now we do the script hook once when you move several files. But then the link to the pub and the file is lost in the script hook as there is no 1-to-1 correspondence anymore. So I think we need to use separate script hooks for each file. >>> 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. > > Sounds good. We can certainly limit it, instead of the dozen > methods we had before to do the same thing. It needs to be in > BibItem because of the document-relative paths, though, doesn't it? > I was thinking of a method [NSURL URLWithString:basePath:] or something. I seem to remember that I thought it may be useful in other places, but I don't remember where. > Would it simplify things at all to have a -icon accessor on > BDSKLinkedFile? It would be interesting to see if we could > eliminate some of the Omni image caching and use IconRefs instead > (providing it didn't kill memory usage; I'm assuming the IconRef > for a PDF file is the same as the IconRef for another PDF file, > unless they have a custom icon). Do we use the file icon anywhere? Christiaan ------------------------------------------------------------------------- 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
