On 15 Jan 2009, at 6:28 PM, Gregory Jefferis wrote: > > > On 2009-01-15 16:50, "Christiaan Hofman" <cmhof...@gmail.com> wrote: > >> On 15 Jan 2009, at 9:48 AM, Gregory Jefferis wrote: > >>> On 2009-01-15 01:31, "Maxwell, Adam R" <adam.maxw...@pnl.gov> wrote: >>> >>>> My concern is mainly that it's a hidden preference for a shell >>>> script that >>>> runs at times the user may not expect (only when a file is dropped >>>> on the >>> I supposed I was thnking that it wouldn't be enabled unless the user >>> did >>> something. >> >> And then forgets that he did... You've no idea how often that >> happens, >> and it adds an enormous amount of email slack to figure it out when a >> bug occurs. The point is that there's no UI where the user can see >> what's turned on and what isn't. > > OK sounds like I'm overruled on that one. Script Hook it is. > > 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. > >> I just added the extra support to the import command that would make >> this possible to handle with the Import Publications script hook, >> as I >> described in a previous email. At an appropriate time I can add a >> skeleton script hook (everything except for the file->DOI routine) as >> a sample to the Wiki. >> >> Christiaan > >>> Overall, if script hooks didn't have to call applescript (and I >>> guess the >>> applescript can chain a shell command) or if there were to do what >>> Mike was >>> suggesting - little python scripts as plugins - I would be v happy. >>> >> >> I wish Apple had a way to handle generic scripts, not just >> applescripts. Unfortunately OSA and related stuff is a mess nobody >> wants to touch. > > Yes >>> More generally, I think having a plugin mechanism is good because it >>> encourages interaction with engaged & more satisfied users ie good >>> for the >>> long term viability of the app. Plus there is a pretty clear >>> separation of >>> responsibility. > >> 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. > And I > recommend using git svn whoever tries it! BTW, does Xcode work with git svn? Christiaan ------------------------------------------------------------------------------ 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
