On Tuesday, January 08, 2008, at 03:42PM, "Alexander H. Montgomery" <[EMAIL PROTECTED]> wrote: > >On 2008-01-07, at 11:04 PM, Adam R. Maxwell wrote: > >> >> On Jan 7, 2008, at 8:35 PM, Alexander H. Montgomery wrote: >> >>> Actually, it's not about *visual* differentiation (which I can do), >>> but differentiation that can, say, be discerned by an AppleScript >>> or a >>> Smart Folder. (For the record, 4938 refs, 3119 single files, and >>> 304 > >>> 1 file). >> >> Thanks, that's a pretty important distinction! I hacked some trivial >> Finder label support in, but it'll be disabled until after the next >> release (if it ever does make it in) since it has the potential to >> kill performance. It'll take some work to make it aesthetically >> pleasing, also. >> >> You'd probably have to AppleScript Finder to get/set those labels, >> even if we do display them. It might be possible to use smart folders >> with Finder labels, but extending them to arbitrary tags would take >> some thought. > >I suppose they could be stored in some bdsk-file-1-attrs field...
Yeah, that just gets messy when you start adding too many fields, and then you have to deal with BibTeX limitations. We could add attributes into the alias blob for each field, though...which would allow you to get/set via AS, and sync them between machines without syncing the individual files. Hmmm. >>> For example, I put together syllabi with an AppleScript that copies >>> references and PDFs to a separate directory for easy distribution. >>> The >>> AppleScript can't tell the difference between a local file that is >>> the >>> actual PDF and a local file that is a related PDF. But if I could tag >>> the correct local file (or, much easier, tag the incorrect ones!) >>> then >>> an AppleScript or a smart folder could do it. My current smart >>> folders >>> allow me to find articles that don't have PDFs (of the article) >>> easily; the new architecture doesn't. >> >> One suggestion is to reserve the first slot for the "actual" PDF. >> This is a drawback of having everything in one bag, but at least it's >> ordered. > >True; a drag-and-drop arrangement interface would work (but wouldn't >distinguish between an entry that had one PDF that was the article and >an entry that had one PDF that was a summmary of something...) Hopefully you know that you can drag files to rearrange them currently, and the order will be preserved? That's sort of tedious, but you can probably script it as well. >> The tagging ideas will probably stay on the back burner for a while. >> I like xattrs and they're fast to read/write, but I'm not sure if it's >> worth the support costs... > >Yes, there seem to be a lot of PEBKAC problems involved with Skim's >use of xattrs (really due to lack of good support for xattrs by Apple). That's what I was thinking of as well :). Apple's support for it is half baked, though they've fixed some of the worst problems in Leopard. Size limits are still unclear. -- adam ------------------------------------------------------------------------- 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-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
