On Wednesday, November 28, 2007, at 01:51AM, "Christiaan Hofman" <[EMAIL PROTECTED]> wrote: > >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:
>>>> 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. The only other thing I can think of is queuing a notification in BibItem if anything was converted to the new scheme, then having the doc show a prompt. Maybe with a disabling checkbox so the hardcore path users don't see it (and we wouldn't even queue a notification in that case). >>>> 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. Yeah, if adding didn't trigger an autofile & script hook, nothing would happen. Perhaps the same disabling-notification pref could be used to set the fileview to non-editable? We'll have to pick a cutoff point for functionality. >>>> 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. Oh, I didn't realize that. Having a separate hook for each file sounds right to me, though. [...] >> 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? I think the only place it would be used is in the tableview. I guess for legacy support we can't get rid of that stuff, so I think we can forget about that idea. 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
