On 28 Nov 2007, at 6:07 PM, Adam R. Maxwell wrote: > > 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). >
I don't think that works well, it would get you a lot of those prompts. My idea was more like the present situation, perhaps with different conditions. That could also be a preference setting. >>>>> 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. > I changed it that way. It also allows passing the old and new path to the script hook. > [...] > >>> 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 But the tableview only shows the old style fields, not the linked files. Also those are useful to see which files are present or missing in case you want to convert. And another thing is import. When would fields in imported items be converted to linked files/URLs? Is that a task for the parser or would it be done when the items are added to the document? A small remark: what about using"Bdsk-File" as the first field name instead of "Bdsk-File-0"? 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 [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
