Implementation of hyperlinks in Scrivener's references panel


Path links (file:////) are not only clickable but can be directly viewed with quicklook in the references panel. I have noticed that hyperlinks (x-devonthink-item://) are clickable whithin the body of a document, but not so in Scrivener’s references panel.

Since that panel is the right place for links, is there a technical impossibility for hyperlinks to be clickable and viewable as well? I often have to modify and refine the names of my annotations in DevonThink, what leads to links to them not working in Scrivener.

I wonder if there is a technical impossibility for this, or if you can recommend a workaround for this?

I see now that when I select the hyperlink and hit Cmd-L + Return, it opens the externally linked file. Yet, it would be much better being able to click or view the file with quicklook in the reference pane, the same as it is now with file paths. If possible.

There seems to be two different things you are asking here, so to answer both separately:

  1. You should be able to double-click (on the icon of course) and have x-devonthink-item References open the linked resource in DTP. The last time I checked this was working just fine, anyway.
  2. To the best of my knowledge it is not possible to use Quick Look on links like this. The best way to think of this style of link is like a message that you can store and send to software whenever you trigger the link. In the case of DEVONthink and Scrivener, these messages will cause the software to display the file that the link points to. Other programs might do other things with these kinds of messages. Either way, once you send the message that’s it, the Mac takes the message, consults which program should handle that type of URL, sends it to the program, and then the target program does whatever it is programmed to do when it gets a message like this. At this point, even if DTP could somehow be aware of the fact that Scrivener originally sent the message, there is no framework within this system for data to be sent back to the message sender. Without any data being sent back to Scrivener, no file can be located and with no file you can’t have Quick Look doing its thing.

A file:// protocol link on the other hand actually points to a location where there may be a file. If there is a file then Scrivener can use the Quick Look engine to display it directly.

You are right. Hyperlinks in Scrivener’s reference pane do work when clicking on the icon. I was wrongly clicking the file name, as I do in DevonThink -where files have no icons. You are also correct about quickview. I’ve seen now that hyperlinks to files in Bookends cannot be viewed in DevonThink either.

Yet I still see a point to use the reference pane in Scrivener for references (source texts and annotations to them), instead of importing them into the rtf area, which it is better to reserve for writing. If source text and annotations don’t get imported into the writing area, but remain easily viewable in the reference pane, the separation between project reading and writing is clearer.

For that to happen without lots of chances to loose most links to files, one should:

  • Have the choice between inserting a path link or a hyperlink into Scrivener -for instance, with drag + Ctrl, as other apps do. This way, hyperlinks to some annotations could be placed in Scrivener’s reference pane (in outliner view), as one reads and annotates pdfs in DevonThink.
  • Have the choice to transform hyperlinked files in the reference pane into path links. The user could decide to do this when done with the bulk of annotations, signaling the passage from the reading to the writing stage.

I realise a similar workflow can be achieved by importing annotations containing a hyperlink in their body of text into the research folder of Scrivener, and splitting the view when writing. But this way the annotation becomes disconnected from its DevonThink original at the moment of importing it, which may well be before the reading stage is completed. And it doesn’t make good use of the reference pane for references.

Another observation about hyperlinks in Scrivener is that they cannot be dragged into the Research area as files, as path links can. I don’t know if that is technically possible. In their turn, URLs are not viewable either, but they are draggable. However, both .html and .webloc formats are viewable with quickview in Mac’s finder.

Whatever the case, this is a great app to work with. And after the latest facelift, a more pleasant one as well.

I think it would help me to better understand what you are asking for you describe the steps you are taking in both DTP and Scrivener, naming whatever menus or buttons you use. I’m not much of an expert in DTP, and to be frank when you first said annotations in DTP, I thought of stuff like the red arrows and yellow “stickies” you can put on PDFs. So I don’t really know what you mean when you say you want to convert an annotation in bulk to a path link (to provide one example). I just don’t know what is being referred to here in terms of features.

If I understand correctly, as nice as that would be, it’s simply not possible. A URL that is a message to another program cannot be used to extract information from that program and display it. Thus using x-devonthink-item style links is not conducive to displaying material in a Scrivener split, and requires using a DTP window in conjunction with the project window. To my mind that seems a better solution than a Quick Look panel anyway—in a DTP window you can annotate. So that’s just a trade-off to using that style of link. If you copy the direct internal file link to DTP, the trade-off is that although you can view it more nicely in Scrivener, as you point out, the URL may very likely get broken as you continue to use DTP. So that’s the trade-off with that approach.

We don’t have any control over what the Quick Look engine can display or not. That is, like the printing system and many other things, just a part of the Mac. What Finder can do with Quick Look unfortunately has little bearing on what we can do with it. Apple has access to stuff nobody else does.

HTML files are another matter. How those are imported are governed by your import preferences. One method, the one I prefer, extracts the text out of the file and imports it as RTF. The default however is to import the HTML as a self-contained WebArchive file.

Thank you for your reply. I will first address one of the issues.

Needless to say, I would like to keep my reading (DevonThink) and writing (Scrivener) connected, if possible. Would the link break if Scrivener instead created an alias? If you select a file in Mac’s Finder and press CMD+l, an alias is created. Dragging a file whilst CMD+Alt pressed does the same. Whatever the changes to the contents, location or name of either file, the alias still finds the original file.

The above can be done both in Finder and within the same DT database. DT’s menus offer the possibility to “replicate” files, as opposed to “duplicate” them. Although in DT when the name of one of the files is changed, so it is the other one’s, as long as they are indexed by the same DT’s database. This does not happen with the keyboard or dragging procedures. Nor it would be necessary in Scrivener.

The CMD+l procedure might be different from the command line ‘ln’. I’ve noticed that this way when the location of the original file is changed, its alias cannot find it.

The other advantage of aliases is that they can be viewed with quicklook.

Yes, Scrivener can store aliases to files, but they won’t be useful to you unless they are in the Binder. You can put aliases in References, just like any other kind of file, but Quick Look doesn’t work with them that way. To put an alias in the binder, either drag and drop an existing alias like normal, or if you don’t have one you can use the File/Import/Research Files as Aliases… menu command, and select the PDF file from within the DTP package. An aliased file in the binder will act just like a fully imported file. It will have its own document notes, reference list and be viewable in the main editor.

(The rest of this is trivia.)

That is a different approach than the alias. Replicants (or “clones” as they are sometimes called in other outlining software) are multiple entries in an outline to the same resource—just a way of placing a resource into multiple areas of the hierarchy. In Scrivener the closest thing to something like that is the Collections feature. If you add a file to a collection, you are making a second outline entry for that item—but both of them point to the same item. Thus changing the title, text or any other aspect of it from any of these outline nodes will impact the central resource. So it is really better to think of clones or replicants as being “the file itself”, because they really are in all senses of the word, the only thing special is that you’re using a program that allows you to display a file in more than one folder at once.

Yeah they are different, and specifically with the ln -s command you’re creating a symbolic link, not an alias (yes, Finder does conflate the two in its “Kind” designation). Symlinks are much more like a file:// URL in a hyperlink: it’s a static piece of text describing the path to a resource that may or may not be there. Move or rename the file, and a symbolic link will break. Place a file where it expects, and it will suddenly start working again. The ln command can also create what is known as a “hard link”—and that is much more like an alias in that it points to the file using the machine address for the file rather than public interface, path + filename.

So, confusingly, the Mac has three different methods of linking to files. :slight_smile:

Thank you for your knowledgeable explanation. I had noticed the different behaviors but the different concepts weren’t clear to me. If hardlinks are different to aliases, I wonder it there is a command line equivalent to the CMD+l keys combination.

That has really changed the topic of my question to the implementation of aliases in Scrivener. I didn’t know about it and it’s great news. Now I think there is just one missing feature in Scrivener for being able to use it for the academic writing workflow I described.

  • Research folder / Reference panel: So far I can’t see the point for Scrivener’s Research folder for writing a long dissertation. As I see it now, there I would place only generic files for loose referencing. I am used to working with outliners, lately NeO, therefore I would like being able to place, in each section of Scrivener’s outline view, aliases to the files I will need when writing that section.

If I understand correctly, importing files means those supporting notes will appear as items of the outline of my dissertation. Since they are not, Scrivener’s outline will become a confusing mix of my dissertation’s sections and a high number of entries, which are just supporting files but will be undifferentiated from the sections of my dissertation in Scrivener’s outline.

In order not to appear as sections of my dissertation’s outline, I think that aliases to supporting files should be in the Reference panel. Actually, I don’t care if the original aliases to those .rtf files are in the Reference panel or in the Research folder. Although it would be a messier workflow, I could use the Research folder as an unordered bucket and put in the reference panel of a section an internal link to the desired alias.

  • Imported files / hyperlinks / path links / aliases: Scrivener is not meant for reading, so I don’t take notes to the pdfs I read in Scrivener. Those notes are nicely handled by DevonThink (.rtf files linked to the page of the .pdf they refer to). Scrivener supports the rendering of aliased pdfs and images in the Research folder. I guess that implementation is different from the CMD+l we talked about in a previous posting. I can’t see the point to plague the Research folder with hundreds of aliases to long academic pdfs. What I need to view when writing are aliases to the several short .rtf notes in which I have skimmed their content.

It could be that Scrivener makes possible a better workflow that I have not yet grasped. Is there any video you can recommend to see a well executed example of using Scrivener for the writing of long academic works?

Nevertheless, I think the availability of aliases or internal links to .rtf aliases is the only missing feature of Scrivener to handle an alternative workflow, mediated by an outliner used as such (only for the work’s sections), with the wonderful capability to keep updated aliases to external text documents for reference that OS X makes available (CMD+l).

Not to my knowledge, at least in a pure sense. You can run AppleScript from the command-line using the osascript command, though, and you can use AppleScript to create aliases.

There are a couple of points here, to address the second one first: I would say that sounds a lot like References. :slight_smile: I know it’s not—I used to use NeO (more back when it was called TAO), since not everything is done inside the outline tree itself but rather in a special panel that is “beneath” the item—but functionally you get pretty much what you are describing with References. Why are references not in the binder? It’s a design decision, that’s really all there is to it. :slight_smile: Both systems have their merits, but having a list of “bookmarks” attached to a document seems more intuitive than mixing these concepts into the outline tree.

Okay, as for the point of the Research folder for a long dissertation, I can’t really say what does and does not have a point for you. I would say in my opinion that there is a point where Scrivener’s design weakens under tons of research, and so having everything in the binder (to be clear, you don’t need everything in the Research folder, that’s just a handy starting point—rename it, give it another icon, make ten of them, whatever) becomes more trouble than it is worth. Where precisely that line falls really depends on the person using the software though (and possibly the speed of the machine they use). I like to create a least two backups every day, so a few hundred megabytes is enough to make me want to start optimising the main project. On the other hand I’ve seen people dump hundreds of gigabytes into their projects. So no, I don’t believe it is fair to say that Scrivener’s research system categorically has no point for long dissertations. :slight_smile: It might not for you however, and that is fine too.

I don’t see how that would become a confusion since imported aliases to PDF files and whatnot wouldn’t be directly intermingled with your dissertation outline. That is why there are two different top level folders: everything descending off of the Draft folder is potentially your dissertation in progress (it is possible for outline elements to be “hidden” from export, either procedurally or individually). In fact it is not possible to put PDF files, or even links to PDF files, in the Draft folder for this reason (as well as the fact that compiling a .docx with .mov files referenced in the middle of the text would make no sense at all).

This is one important difference between an outliner like NeO and the one in Scrivener: its root level is one step higher than “the document”, and can contain sibling items and folders to that document root. It seems you’re thinking of the binder as being one outline, and thus everything within that outline should be in service of one cohesive representation of structure in the document, but that statement is only true within the context of the Draft folder. Once you get to that point, it makes more sense that you can only put “folders” and “files” into the Draft folder—just like you can’t drop an MP3 file into the middle of a NeO outline.

All of this is why I like to think of Scrivener more as a hybrid outliner than a pure outliner, such as NeO and OmniOutliner. Outside of the Draft folder, it feels more like DTP or Finder. You drop in a PDF and you get one entry to that PDF in the folder tree somewhere. But in the Draft? Well it would be pointless to use Scrivener in such a way where that was one single document. Even the least complex usage of the software—one outline item per chapter—is still an outline in the sense that we have a long block of text broken up by a hierarchical representation of its internal structure (and potentially its external structure as visible to the reader by way of page breaks and section headings). And of course you can outline, as a concept, outside of the Draft folder as well.

The basic tools to work with your dissertation are the same as your research tools. The loading a PDF in the main viewer is just as easy to perform as viewing a section of your dissertation. All of this is meant to be mixed up in the UI model, the underlying philosophy of design in Scrivener is arguably that research and writing material should have equalised accessibility in an integrated environment. Is that approach for everyone? Absolutely not, but that is why Scrivener was originally created: to completely break down the divide between writing and referring.

Well again, I can’t really disagree with you on that point, but it’s how the technology works (or doesn’t rather). For whatever reason the third-party access to Quick Look doesn’t poke past the alias-as-file and examine the file-as-aliased. You get an alias icon, not the original material.

But again, I don’t really understand the compulsion to avoid outlining/organising your research material in the binder. Why would the alternative be dumping everything into the top level Research as a “bucket”? Why not sort that stuff into topical folders, give them keywords so that relational searching can be done, etc.?

Hmm, yeah I can think of better ways of approaching things with Scrivener. Here’s an easy one based on your earlier description of putting references into the outline tree as child items beneath the thing they relate to:

  1. Import the alias to the PDF into the binder.
  2. Import the note files into the binder.
  3. Drag the notes “into” the PDF, nesting them as child items beneath the PDF’s outline node.

All right, now click on the PDF in the binder, and you can read the PDF. If you want to see your notes on the PDF, at any time hit Cmd-3 (View/Outline menu) to switch to Outliner view. When you’re done, use the same shortcut to turn the Outliner off for the current node you are viewing and it goes back to showing the PDF.

Does that make more sense? That’s why I like to think of this as a hybrid outline. You can outline around your research material, making these files a part of how you structure your thinking and knowledge. A JPEG can be a headline element or parent to other supporting JPEG files, interspersed with notes on those files. One might not even open a note file into the main editor if it is a short note: you could type the whole note into the synopsis field.

Hopefully you get some new ideas out of that. I’m not saying any of this is the right way to use Scrivener, but I will again say I don’t quite understand the hard dichotomy between “reading” and “writing” and so forth, because to me, and how I’ve always used Scrivener, one of its crowning achievements is that it obliterates the walls between files in the body of information that constitutes your work and the material you use to create that work.

I agree it wouldn’t make sense to use the top level of the Research folder as a bucket. My rtf notes, not the pdfs they refer to, are meant to go to different sections of the dissertation’s outline. Scrivener doesn’t use or import Apple tags as far as I know. As I see it now, reproducing the outline of the Draft folder in the Research folder would be less time consuming than manually retagging each note. This way I could populate the Research folder’s outline with the notes. And later, reference to them in split view, Draft/Research.

It is in DevonThink that I read pdfs, annotate them with hyperlinked rtfs, and tag. I believe DT is better at that, as I have no doubt that Scrivener is much better for writing. I see reading and writing as separate stages because they are done in separate apps. I agree that further reading and annotating in DT will be done during the process of writing, and this is why I hoped that aliases or hyperlinks would be capable of keeping both systems connected. I thought that aliases could be viewed with QuickLook because they do in Finder. Thanks to your explanation I have understood that the reference panel is out of the question.

It is difficult to envision a workflow before working with it. I will keep your post for reference. I could also try replicating notes to an external folder indexed by DT and synced to Scrivener, and see how that works. I know Scrivener is the best app for the job and hope to reach to a satisfying workflow with it. Is there any video you can recommend to see Scrivener well used in a practical project?

Thank you for the thorough support.