Re: [Bibdesk-develop] branch vs. trunk

[Adam R. M. <ama...@ma...>]

 
On Tuesday, November 27, 2007, at 04:21PM, "Christiaan Hofman" <cmh...@gm...> 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.

>> 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.

>> 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.

>> 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?

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).