Would it be possible to add x-callback-URL to Scrivener? I am coming to rely on it to keep various strands of a project together…
Hi - This appears to be an an iOS-only specification, and for that reason alone it may be difficult to justify for inclusion. Perhaps you could describe how you would put the capability to use? Someone might then be able to suggest an interoperable approach to the same objective.
Rgds - Jerome
I’m not exactly sure what you have in mind either as that’s an umbrella mechanism, but it’s worth pointing out that on the Mac there is an x-scrivener-item:// protocol that you can use to link to an item in a project, from anywhere. Within Scrivener itself, these are handled transparently if you do such things as drag an item from one project’s binder into another project bookmark lists, or into its text editor as a hyperlink.
Given how the links target a project by full path name, the mechanism is not cross-platform compatible.
Details in the user manual, under §10.1.6, External Links, starting on page 216.
Thanks for that. The x-scrivener-item// protocol works.
However, the link generated by (right-click) copy document link or Edit > Copy Special > Copy Document as External Link gives a linbk beginning with
x-scrivener-item///
Like this:
x-scrivener-item:///Users/iangreig/Dropbox%20(Personal)/Scrivener/Scrivener%20projects/TLW.scriv?id=56FEA580-141B-4473-81F0-B40F4A028C3D
This link isn’t recognised as a link (and doesn’t work)
Edited to the more usual form it works fine.
x-scrivener-item:// (etc)
So it works for me, with a bit of extra work from me at the moment. No doubt someone who understands these subtleties will explain this!
Thanks AmberV for pointing me to Section 10.1.6 in the new manual
It would help to know under which context this valid link format fails. I don’t know what “protocol://path/to/file” would mean. “protocol://” is a thing all by itself, and so is “/path/to/file”. All paths in URIs are absolute, meaning they start from the root and require an initial slash. That is why we have “file:///path/to/file” links as well.
It is a shorthand (or to be more technical about it, a no-authority request, which according to RFC-3986 should be interpreted as the end-user’s machine), where the more complete URL would be, “file://127.0.0.1/path/to/file”, or “x-scrivener-item://localhost/path/to/file”. So you can see that’s where removing the slash makes no sense: “protocol://localhostpath/to/project”?
If the software you’ve pasted this into doesn’t take the shorthand method then try that. But “something://path” is never valid (which isn’t to say some parsers might fix the broken scheme internally).
Further reading: Why do file URLs start with 3 slashes
I keep my callbacks in Day One. Day One didn’t parse the ‘///’ form but did see the ‘//’ as a link.
When I tried it with Apple Notes it was the other way round. With Agenda, either form worked.
The Scrivener callbacks don’t look like ‘proper’ URL callbacks, and they don’t seem to work from another platform – I tried iOS. (I use Windows in another area of work but I haven’t tried it.)
It would be good to have a callback link that would call a Scrivener doc from whatever platform, but I guess that would involve a step change in making Scrivener web-accessible.
Okay, I downloaded the demo of Day One and looks like their URI detection is incomplete as you note. They also failed to recognise basic file system links as well, like “file:///Users/accountname/Downloads/test.zip”. That’s something you’ll have to take up with them.
It’s an x-scrivener-item link, not an x-callback-URL link. It isn’t improper for an entirely different protocol to use a different schema.
As for trying to use them on another device, this is a link to an item in a project on your Mac. It’s not going to do anything from a different operating system. The best it could do there is try to load the item on its system, but since paths are different on every operating system, that’s why I said before they are not cross-platform compatible.
It wouldn’t have much to do with the WWW, again it’s a problem of paths. What you’re asking for is basically the same as asking for Word to be able to load any .docx file on any operating system with a single URL that works everywhere you try it. Even if you set up your folders the same everywhere, E:\Projects\something.docx isn’t going to work on a system that needs /Users/youraccount/Projects/something.docx, nor on a system like iOS that just looks back blankly at the concept of “folders” in the first place. 
Hopefully that makes more sense.
Thanks, AmberV, helpful clarity.
I would note that iOS can do folders now, so a callback from Mac to iOS or iOS to Mac could invoke the Scrivener app and folder (they would be synced) on either platform. I understand that a full callback scheme would present some challenges.