On Wednesday, November 28, 2007, at 10:01AM, "Christiaan Hofman" <[EMAIL PROTECTED]> wrote: > >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.
With a queued notification it would only give one alert per document, after it finished opening. How were you thinking of doing 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). >>> >>> 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. Yeah, I'm not suggesting we get rid of them. The question is whether we should allow displaying the bdsk-file in the main table. I'd rather leave that out for now. >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? Imported from where? External groups? I haven't even considered that...mine never have files associated. >A small remark: what about using"Bdsk-File" as the first field name >instead of "Bdsk-File-0"? I'd prefer to keep an integer on all of them, although starting at 1 instead of 0 would be okay. I think it makes coding a bit simpler, and possibly manipulation with a text editor or other tool. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
