On 28 Nov 2007, at 7:27 PM, Adam R. Maxwell wrote: > > 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? >
Wouldn't it also give you such a prompt any time an item as added? That can become annoying. > [...] > >>>>> 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. > Wouldn't do that. >> 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. > From external groups and various parsers. Attached URLs may be more common. >> 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 I like 1-based counter for the fields better. It' not too important as it will be mostly hidden. 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
