On Thu, Jan 15, 2009 at 1:03 PM, Gregory Jefferis <jeffe...@gmail.com> wrote: > On 2009-01-15 18:33, "Christiaan Hofman" <cmhof...@gmail.com> wrote: > >>> I think as Christiaan says, there would need to be two script hooks >>> for most >>> generality allowing: >>> >>> 1) path_to_PDF -> DOI >>> 2) DOI -> Citation >>> >>> ie (1) could provide an alternative way of finding dois given a pdf >>> file. >>> And (2) could provide an alternative way (besides PubMed) of finding >>> the >>> citation info if you have a doi. Perhaps it would be nice if this >>> script >>> was allowed to return the url pointing to the citation info rather >>> than have >>> to return the citation info itself. >>> >>> Christiaan, does this sound like what you are thinking? >> >> No, I think you misunderstand the purpose of script hooks. They can't >> be used to get information. They're just executed when certain actions >> take place, to perform some /additional/ actions. They're one way: >> info goes in (basically which items were changed and what was >> changed), nothing comes out. So in particular, they can /never/ be >> used to /replace/ something BD does. >> >> This also means that it cannot be used to /add/ the item, or get info >> necessary to create the item. It is called /after/ the item was added, >> not before: the input for the script hook is the item (which didn't >> exist before adding), and BD would have no way of knowing whether the >> script hook would have added a new item (so that can't be the >> responsibility of the script hook). The idea is that the script hook >> modifies the item when it's imported, based on the linked file. >> >> There's also not 2 script hooks involved, there's just one: "Import >> Publications". What I was saying is that the script hook needs to >> perform 2 /tasks/ in order to simulate the updating. (1) could be >> performed by calling another script, or the script hook could do it >> itself. (2) can now be easily done using BD's AppleScript support, or >> the script hook could do it in some alternative way. >> >> The idea of what the script hook does (/after/ adding the item with >> the linked file): >> >> 1. check whether the info is not yet filled in (fields are empty) >> 2. get the linked file >> 3. file -> DOI (completely custom) >> 4. DOI -> new pub (e.g. use the "import" command, which can now use >> +itemWithPMID:) >> 5a. copy fields from new pub to imported pub and delete new pub >> 5b. or link file to new pub and delete imported pub >> >> Alternatively, the script hook could just replace the imported pub by >> the temp pub. > > Thank you very much for the explanation. It's a pity that it's necessary to > do the shuffle with a second new publication filling in the original, but I > think I've understood. Does 5 happen by calling a scriptable publication > merge function? I've been thinking for a while that a merge function would > be quite useful. > >>>> I also think some kind of plugin mechanism can be good. But it must >>>> be >>>> well designed, not just added incongruously. >>>> >>>> Christiaan >>> >>> Maybe a side project for when someone has some time on their hands... >> >> An important point I wanted to make is that first a design needs to be >> discussed before it makes sense to add a project. > > Absolutely. Mind you if it's compact enough a good way to start discussion > can be a patch sent to the list. > >>> And I >>> recommend using git svn whoever tries it! >> >> BTW, does Xcode work with git svn? > > No, fraid not. But I don't find it a handicap. I use the built-in git-gui > for commits and gitk for browsing history. They're not pretty but they > really work well. Specifically for Mac, Gitx provides most of the > functionality of gitk and and some of git gui (but important stuff is > missing, like selecting commits line by line).
In my version 0.5 of GitX you can indeed select commits line by line - there's a blue "Stage" button next to each chunk of diff, and you can leave some chunks unstaged when you commit... -mike > > QGit (cross platform with QT) is supposed to be good, but I haven't tried > it. > > Best, > > Greg. > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Bibdesk-develop mailing list > Bibdesk-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bibdesk-develop > -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/ ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Bibdesk-develop mailing list Bibdesk-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
