Hi Jon,
I just wanted to check to see whether it would be at all possible to add the "Quick Add" feature to the AppleScript event library for Bookends. It would be wonderful to have a function that would autofill a complete reference from, say, an isbn directly into my open library without needing to leave what I was doing to enter Bookends. I can already do this with some websites on Safari, for instance, using the current reference entry event library, but being able to just enter an isbn or doi would be fantastic.
Thanks again for all of your work.
Zach
[Feature Request] "Quick Add" AppleScript event
Re: [Feature Request] "Quick Add" AppleScript event
I'll add this to the list of requests to be considered.
Jon
Sonny Software
Jon
Sonny Software
Re: [Feature Request] "Quick Add" AppleScript event
Thanks for that! It just struck me that I could make a pretty useful PopClip extension for Bookends with that kind of functionality, if doable.
I'll look forward to it but fully understand that the list of desired features is likely quite long.
I'll look forward to it but fully understand that the list of desired features is likely quite long.
Re: [Feature Request] "Quick Add" AppleScript event
I do like the idea.
Jon
Sonny Software
Jon
Sonny Software
Re: [Feature Request] "Quick Add" AppleScript event
zvh: you can do this using system events scripting, this is what my alfred workflow currently does to support quickadd:
BUT the problem with system event scripting is that it is flakey, it critically depends on those delay 0.x timers and if the machine is doing something else those timers can cause the next event to miss the window where they will work. So I would love an applescript event too! +1
As an aside, another excellent way to do this would be to support URL schemes. Bookends already supports a URL scheme so that the browser extension works — bookends://sonnysoftware.com/#refid takes you to that ref. This could be extended so that bookends://sonnysoftware.com/quickadd/#DOI would quickadd the passed doi. The advantage of this compared to an applescript event is that it works with any scripting language or other tool.
Code: Select all
#!/usr/bin/osascript
tell application "System Events"
keystroke "c" using command down
tell application "Bookends"
activate
delay 0.1
end tell
tell application "System Events"
keystroke "n" using {command down, control down}
delay 0.6
keystroke "v" using command down
delay 0.1
keystroke return --comment this out if you want to edit text before search
end tell
end tell
As an aside, another excellent way to do this would be to support URL schemes. Bookends already supports a URL scheme so that the browser extension works — bookends://sonnysoftware.com/#refid takes you to that ref. This could be extended so that bookends://sonnysoftware.com/quickadd/#DOI would quickadd the passed doi. The advantage of this compared to an applescript event is that it works with any scripting language or other tool.
Re: [Feature Request] "Quick Add" AppleScript event
Hi iandol, thanks so much for your help! And for your Bookends Tools, of course, which were the resource that first let me know everything that might be done with what I had mistakenly thought for a time to be a limited scripting dictionary. This is one of the tools that I don't make much use of, however, due to its reliance (as you note) on Apple Events. I do have something similar in Keyboard Maestro that activates the app and then waits for the "Quick Add" menu item to appear before selecting it. This mitigates some of the flakiness but is still not the most elegant solution. I'm quite excited by the idea of a PopClip extension or Apple Service that might take text selected anywhere and add the full reference to Bookends, whether via ISBN, DOI, or even RIS, XML, or BibTeX. I've even created a little script that converts BibTeX to RIS and then uses the ADDA event id to add it to Bookends, so the rest should be mostly trivial if an event id for the "Quick Add" feature can be implemented.
And I agree, a URL would likely be more flexible, although I'd be quite happy either way!
And I agree, a URL would likely be more flexible, although I'd be quite happy either way!