I just posted in the tech support section but it occurred to me that this is a feature request as well.
Here is my scenario:
I want to copy/drag text clippings from outside scrivener (e.g. stored in DT Pro) and have Scrivener create a new doc (scrivenings?) from the clip with a url link back to the file (if in DTP then a “Copy Item Link” for a permanent link).
I especially like the new feature of writing in compose mode with separate floating “quick reference panels” so DTP’s item link doesn’t really help in this regard.
Also
A related request is to have be able to hover over links and have them appear as quick look panels and/or open as floatable quick reference panels. This would avoid the need to import docs when only using them a references or writing prompts, esp. in the compose mode.
Could you clarify what you mean, perhaps by way of an applied example, for the first bit? I’m not following why copying the DTP item link and either using that as a hyperlink target or a Reference is not working for you. These things should be working—I just tested them again and I can pull up a DTP entry with a single click (or double-click for References) in Scrivener.
For me, if I use Edit/Copy Item Link in DTP, I get an RTF hyperlink using the entry name for the visible text that I can paste directly into Notes or the main editor in Scrivener—or if I paste into a plain-text field like References I get the raw URI.
If you mean this should be generated when simply dragging a selection of text from another program, there is no way to do that as far as I’m aware. All that gets sent to Scrivener in that event is a blob of text. I don’t even think it knows which program it came from, let alone any specific pieces of bespoke meta-data like URIs. The program doing the text delivery would have to provide that information in a standardised fashion (which I don’t even think exists on a Mac, unfortunately).
I think I found a temporary workaround but first I’ll try to exemplify further.
If I’m writing in Scrivener’s compose mode and click a previously pasted/copied url link from DT then the DT doc window opens (as you note) which I can then resize and place beside the compose doc where I want. The problem is that DT is now the active app so when I go to type in Scrivener the DT window disappears behind the dark background fade. Sure, I could made the background fade more transparent to see the DT window but then I loose the advantages of the compose mode in my view (a focused text-only environment).
My workaround is to set the DT window as always on top (in my case using the third-party app “afloat”) but I still have to do this with each new DT doc. Perhaps there’s a way to get all opened DT windows to open floated on top by default but I don’t know how.
Another workaround is to import all the sources into Scrivener and open it as a quick reference but this is extra work and I prefer to keep my scrivener projects as slim as possible. Besides, I want everything in DT for making associations. Here the Scrivener sync feature is very useful.
Oh well, one can always dream.
However I also asked about making the link hoverable for a temporary glance. But this would not be practical as a working reference unless there was a way to select “keep it open” or something… which brings me back to the initial question.
Ah, I see what you’re going for. This is just a bit tricky to do that both technically and conceptually. I mean, we’re talking about hosting another program’s data inside of a floating panel in Scrivener (never mind a tool tip!). Unless the other program specifically ordains such a usage (usually with a software development kit so we could then make a “Scrivener plug-in” for DTP), it’s really not feasible to do so.
The URI hyperlink isn’t going to work because that isn’t a file. It’s an special type of message that can be stored as text, that once activated goes into a central database that DTP manages, which routes the incoming request to resources which may or may not actually exist on the disk. We cannot “load” that resource directly. All we can do is fire off this special message to the operating system, to whom DTP announces itself as a handler for the x-devonthink protocol, asks the OS for permission to handle it, and then takes it from there. At this point, Scrivener is already two steps removed, and by the time the message is delivered, it’s DTP that is doing all of the work. Meanwhile we can’t map directly to the material on the disk, where it exists, because DTP is the manager of that information and will change allocations as its sees fit to keep your data optimised on the machine. Stuff doesn’t stay put, inside of a DTP database, that is precisely why they developed a routing system for addressing data externally, so that we can have a stable “permanent” link to materials that are otherwise unstable and in flux within the internal storage mechanism.
Sorry if all of that is a bit technical! What I’m saying is, there is no stable and dynamic way to extract information out of DTP. All we can do is ask DTP to retrieve the data for us and have it do so itself, which means using its windows.
It sounds like I’ll have to tinker a little more with the compile fade settings. I think I could produce what I’m looking for if I set up a dedicated extra desktop view with a black background (or a second screen) and have compose open up on that but with no fade. That way I can view the DT window and use compose at the same time.
Thanks for indulging me and if have any further thoughts about other possible workarounds I’ll be happy to hear them.
Another thing you can consider, if you have the budget, is to pick up a cheap second monitor. It doesn’t have to be anything special, but a second screen can let you do all kinds of cool things like that. You could set the background to black and run DTP on it.
