I was starting to experiment with Tinderbox’s appleScript support, specifically to get links to individual notes. With that I was able to extract a link to a note. They look something like this:
If I put that into a text document (TextEdit), I can click on the link. It will then open the outline view and select the correct note in the outline view. However, the text window to the right is not in sync with the note. It shows the text of a different note. Does anyone have a clue why that would be the case? Any help would be appreciated.
For background info: This is a piece of getting to an integration of Tinderbox with Hook. Inching my way toward getting all the scripts in place to support that.
I don’t have an answer for you, but thanks for letting us know about Hook. From my initial testing, it’s the app I’ve wanted for years.
I am a huge fan of x-devonthink-item:// links because they just work, even after moving and renaming things, and across devices. I’ve badly wanted a way to create universal links for files outside of DEVONthink.
I haven’t tested Hook across devices yet (I guess it supports dropbox) but after initial testing it looks very promising.
I think Tinderbox will be great for creating “meta views” of files. Super cool.
Actually looking at your example, I suspect this is just a bug. It’s nice to see that TB note links seem to have gotten some love – before, if you moved the note 1555427616 to a different container, then TB wouldn’t be able to find it. But now TB can find the note, which is a big improvement!
I did more testing, and I’m getting the same behavior if I get the note’s URL from the Note menu (even though the link doesn’t have the path in there). So I’m guessing my scripts I wrote for hook do something reasonable. BTW: I cross posted a similar question in the Hook forums as I wasn’t sure if I did something incorrect when cobbling together the applescripts that Hook needs.
Share robust links to emails and versioned (e.g., GIT, SVN) or shared (e.g., Dropbox) files that your colleagues can instantly open on their Macs. Saves you both time and effort.
and was hopeful.
Anyway, multiple machine stuff will be a challenge. I don’t know how Hook is implemented, but I know one OS X feature is “file IDs” or something like that – which is how certain OS X applications are able to locate files even after they’ve been moved or renamed. The caveat is that it only works as long as the file stays on the same physical drive.
That said, Dropbox has a kind of similar feature, where when you copy the shareable link for a document, you can move it and rename it all you want and the link will still work. I had cobbled together some scripts for creating “universal links” based on this, but it was fiddly to work with.
Anyway, I’m speculating. I don’t know how it’s all built under the hood. But I’m keeping an eye on it for sure!
If a note is selected in a Tinderbox document, and Hook is invoked, then Hook in Hook use Copy as Link, it will copy the file:/// address of the document.
If a note is selected in Tinderbox and I use Note > Copy Note URL (or the shortcut), and then use Hook on something outside of Tinderbox (say, a file), then use Link to Copied URL in Hook, one can link something directly to a note.
Thus there is limited (but useful) integration already possible.
Since Tinderbox now has scripting, someone at Hook could write a script that invokes attribute of and grabs the content of $NoteURL and then deeper integration would be possible.
Yep. I noticed bullet point 1 above. Didn’t know about the second bullet point. What I was looking for was a nice icon to paste (as with apps Hook recognizes). I don’t really like the file:/// address string. But it does work. Thanks, Paul.
Edit: weird, but I tested Hook + Tinderbox several times this afternoon, and then it suddenly stopped working with Tinderbox. Hmmm… certainly not a Tinderbox error, that’s for sure.
Seems to be working here after adding a Tinderbox 8 entry in Hook preferences with a Get Name script:
tell application "Tinderbox 8"
tell front document
set xs to its selection
if {} ≠ xs then
value of (attribute "Name" of (item 1 of xs))
else
name of it
end if
end tell
end tell
and a Get Address script:
tell application "Tinderbox 8"
tell front document
set xs to its selection
if {} ≠ xs then
set target to item 1 of xs
else
set target to it
end if
return value of (attribute "NoteURL" of target)
end tell
end tell
Or more “plain vanilla” AppleScripty versions… (Not yet tested with Hook but results tested to be the same as @ComplexPoint scripts).
tell application "Tinderbox 8"
tell front document to if it exists then
tell selection 1 to if it exists then return value of its attribute "Name"
return value of its attribute "Name" -- "Name" of Tbx document if no note selected
else
error "No Tinderbox document open"
end if
end tell
And…
tell application "Tinderbox 8"
tell front document to if it exists then
tell selection 1 to if it exists then return value of its attribute "NoteURL"
return value of its attribute "NoteURL" -- "NoteURL" of Tbx document if no note selected
else
error "No Tinderbox document open"
end if
end tell
I’m not sure that Hook is capable of passing on error messages generated by embedded scripts. In my experience if it doesn’t succeed it just fails silently.
In principle one should be able to use JXA with the script starting with //JavaScript. This is a currently undocumented feature. I myself need to get clarity from our developer who added it! I will reply here when I have it.
Coincidentally, we have very recently added a failure notification in an unreleased build – the feature isn’t complete. We will document it in its release and I’ll update here accordingly. It should (at least optionally) pass on the message. Whether to use a macOS notification or just the status panel is a question. Probably should have a preference for this, and perhaps introduce a “Debug Mode” for Hook.
At the moment following a //JavaScript line with JS values other than string literals returns either undefined or puzzling URL-encoded strings, which is:
encouraging (certainly a sign of some JS evaluation going on)
not yet usable, I think, the expected string return mechanism is unclear (and there seems to be a missing urlDecode phase)
\\JavaScript
"hello" + "there"
→ hellothere
which seems a good start, but then
\\JavaScript
Application("Finder").name()
→ undefined
and least predictably of all:
this
→ %5Bobject%20GlobalObject%5D
Which suggests an opacity or slight oversight at some point in the process.
It will be very useful when it settles down, though.
PS a clue to some kind urlencode ⇄ urldecode gap is suggested by the fact that: