On May 4, 2008, at 6:04 PM, James Howison wrote: > > On May 4, 2008, at 7:57 PM, Adam R. Maxwell wrote: > >> >> On May 4, 2008, at 4:38 PM, James Howison wrote: >> >>> I just added Doi as a default field in my library. Quite a few >>> references already had it. I created a new reference and copied >>> in a >>> value for the Doi field in the Edit window. >>> >>> I was surprised that it didn't show up in the Files section, because >>> those items that had a Doi now had a link to the dx.doi.org >>> resolver. >>> Adding the Doi column did give me a clickable link. >> >> The Doi field is the only way to recognize and support Doi at >> present, >> since it's otherwise impossible to recognize them. Since they don't >> have a scheme, they're not a valid URL for the files pane; if you >> drag >> one in, it shows up with the bizarre generic URL icon, and you don't >> get a thumbnail. I added a delegate method to my source tree for >> opening these, but even that requires a doi: scheme (IIRC) to work >> reliably. >> >>> I tested a bit in a new bibliography and if I closed the bib then >>> re- >>> opened it I got the 'migration' dialog pane, and once I said Convert >>> the Doi link showed up in the Files pane. >>> >>> The same happens for URL (or Eprints fields), so I assume this is >>> about fields typed "Remote URL". >> >> It converts local and remote URLs, just as it always has... >> >>> So is there a recommended way to add Doi so that the library doesn't >>> have to be 'converted' again to have them show up in the Files pane? >> >> Prepend http://dx.doi.org and drop it on the file pane? I wish I had >> a better answer. You'd almost need a separate well to drop them, or >> maybe an AppleScript could read the pasteboard and convert the Doi to >> a URL? >> >>> For URLs (starting with http:) I can simply paste into the Files >>> pane, >>> but this doesn't work when one has a Doi on the pasteboard (I guess >>> because it doesn't start with Doi). (since DOIs aren't URLs how >>> would >>> one sniff that one has a DOI?) >> >> If you have a doi: scheme it ought to accept the drop, but it may not >> open correctly. And you're quite right: you can't detect them, so >> it's hard to improve on this. > > -1 for the DOI Foundation :) > >>> I find it a little non-intuitive that simply adding a URL to the URL >>> field or a string to the Doi field, after one has converted one's >>> library doesn't add them to the Files pane. >> >> If you consider Doi and Url as legacy fields, it might make more >> sense; in general, you should only use Url if it's part of the BibTeX >> type. Doi is an ugly special case; the Doi field does some magic to >> convert it to a resolvable URL. > > > Ok, I'm still coming to grips with the URL situation, post-migration. > > If I paste a URL into the "Drop Files Here" box then a URL thumbnail > is added *and* the URL field filled out, (if it is the first URL for > the item. If it's not the first item then another URL thumbnail is > added)
I believe that only happens if Url is a required/optional field for that type. So for @webpage, it would be filled in, but not for @article. > If I paste the URL into the URL field, then obviously the field is > filled out, but the URL thumbnail isn't created. Right...don't do that anymore; since it's deprecated, it's no longer the primary interface. > If I delete all the URL thumbnails then the URL field still stays > filled out (not sure how I feel about that, but I understand why it > happens). There's no other way to do it... > So there's a one-way addition of the first URL thumbnail to the URL > field and therefore pasting URLs into the "Drop Files Here" box is the > "right way" to do things. > > For DOI that doesn't happen because the drop/paste zone can't > recognize a string as a DOI. > > Pasting 10.1145/1134285.1134336 doesn't work (beeps). > > Pasting doi:10.1145/1134285.1134336 into that zone doesn't work > (beeps, i think you said that worked in your source tree, but it > requires adding doi:). That works here with the current nightly build. Make sure the file pane has focus, but pasting it from this mail message worked fine. > Pasting http://dx.doi.org/10.1145/1134285.1134336 into that zone quite > rightly treats it as a URL and, if there isn't a URL already it gets > copied into the URL field. > > Pasting the DOI into the Doi field doesn't trigger the creation of a > http://dx.doi.org/ > thumbnail, but that does happen if I do a manual conversion, or when > I restart BibDesk. If I choose 'don't ask me again' then it will > happen silently. > > Perhaps if the user has checked 'don't ask me again' (and is therefore > accepting automatic conversions) a Doi pasted into the Doi field could > generate a Doi thumbnail automatically? > > The solution is non-obvious :) Indeed. It might be feasible to extend the current special-case handling of DOI, but special cases suck. You could look into adding a script hook that fires when the DOI field is set, and then the onus is on you to keep it working :). I think that's actually the way DOI is designed to work, but it would have been easier if they'd made it a URL instead of a URI that requires additional context (e.g. as an attribute in XML) to be useful. -- adam ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Bibdesk-users mailing list Bibdesk-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-users
