On Friday, January 11, 2008, at 09:24AM, "Christiaan Hofman" <[EMAIL PROTECTED]> wrote: > >On 11 Jan 2008, at 5:13 PM, Adam R. Maxwell wrote: > >> >> On Jan 11, 2008, at 2:40 AM, Christiaan Hofman wrote: >> >>> It was displaying only the pubs for the author. That does not make >>> sense when you are showing an editor. >> >> Oh, I thought it was displaying all pubs that a person was associated >> with as author/editor/other. Didn't it use -[BibItem allPeople]? I'm >> pretty sure we added that for display and testing membership. >> > >No, it used -[BDSKPublicationArray publicationsForAuthor:], which >used -pubAuthors. ON the othr hand changing the name changed every >author in every field, with the comment that it did so because there >was no way to get the field.
I'm not sure why that comment was there, since it sounds like expected behavior in retrospect :). Being able choose fields as you say is probably better. I guess the support for arbitrary person fields wasn't as finished as I thought. >>> I was thinking about making it more useful by adding a control (table >>> or popup) to choose the fields to display. That could work as a >>> filter on the displayed publications, and also on where a name is >>> replaced. Similarly, I think it can be useful to display (and filter >>> by?) all different forms of the name, so you can easily see if a name >>> is spelled consistently or whether we have collapsed too many names >>> (I'm thinking of Alexander and Alexeev Zamolodchikov). But I did not >>> want to do anything like that before the release. >> >> Yeah, displaying all forms of the name would be useful. Grouping by >> any person would be useful as well (I thought we could do that, but >> apparently not). > >I was wondering if it should be any normalizedName (which is used for >isEqual) or any originalName. What "it" would that be? >What do you mean by 'any person'? You mean any person field? Yes, using a set of all of the persons in a document. It might not be worth the hassle, though. >> I wanted to release last night, but figured I should wait until you'd >> had time to check that file save. It's tested, but I'm paranoid about >> manipulating files. >> >> adam >> > >I have not really test it. Looks like it would be mostly OK, keeping >in mind the restrictions from the comments. But shouldn't the tmp >file always be removed, a file in a tmp location is not really useful >as a backup file. Since -[NSDocument keepBackupFile] always returns NO unless overriden, it'll always be deleted. In this case, the backup file is saved alongside the original so file.bib and file (1).bib are present until the exchange/delete succeeds, which would make it easy to find. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Bibdesk-develop mailing list Bibdesk-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
