When I link a Scabble doc in my Research folder (using “Existing File…”) I would like a dynamic link option that checks (periodically or when I ask for it) if the Scabble file was changed versus the date the link was created or last updated. This will help sell more Scabble and add a great functionality to Scrivener. Then, maybe allow for other dynamic file type links, such as PDFs, etc.
This came up as I created a book and worked in both Scabble and Scrivener, mapping the story flow as I thought it through. I saved it as a linked file but had to frequently change it to the last saved Scabble file to maintain a current view in Scrivener.
WARNING : The following suggestion is intended for Windows users, and could potentially be risky if you are not comfortable with handling computer files.
Having external files in the project's folder
The following is not approved by LL
If you put your scapple file inside your Scrivener project’s folder, a backup of your Scapple file will be made everytime you backup your Scrivener project.
So this way you don’t have to do multiple save as of Scapple to have some sort of backup.
Use a single scapple file, and backup your “mother” Scrivener project whenever you feel like you’ve progressed enough in either Scapple or Scrivener.
You won’t ever have to update any link to Scapple.
If you set yourself a dedicated folder inside Scrivener’s project folder and put your project related stuff in there, this works with any apps-files and whatnot you may want to link to from within your Scrivener project. 
You could have a graphic design file for your book cover keep up to date, for e.g.
Or easily transfer the whole of those external files a project refers/links to from a computer to another along with the project itself. (A zipped backup of the project is all it would take.)
→ In my screenshot, I’ve put the Scapple file straight in Scrivener’s project’s folder so that it could be visually clear. But it is best in all cases to rather create a dedicated folder inside Scrivener’s project’s folder. You don’t want sub-files/folders from whatever app(s) that(those) other file(s) belongs to to end up all mixed up in Scrivener’s folder.
This is how my screenshot should actually have looked :
I replied to your email but do not see it here. My email states:
I just tried this method and it does not accomplish what I want. I want to have a Scapple file in my Research folder that updates dynamically in Scrivener if any changes are made to the file in Scapple. This suggestion you have does not give me what I want.
However, I will try once more, since your email only included the top 50% or your post. Now that I see it all I will try again. Then will report results.
BTW:
To do this I need to save the project. Then (on Mac OS) right click the file to see Package contents, then save the Scabble file (and added folder) to that.
Isn’t this a bit convoluted? Forces users, especially non-geeks, to delve into something (a Package) they normally would not do. Just saying…
The email you received is only a notification.
You can turn that off in your forum preferences.
Whether you want to be notified or not, no point answering such emails.
Refer to §8.1.3, in the user manual PDF, under subheading Viewing Unsupported Document Types, at the very end of that subsection. Scrivener fully supports the notion of loading, working with, and saving resources within the project—there should never be a reason to hunt down the internal document by hand. There is even a keyboard shortcut for it.
That all works for stuff linked into the binder as well, of course, but it’s worth noting that in neither case will the binder item’s modification date increment if the original source changes. That may be something we could improve, maybe as a secondary function of the refresh button in the footer bar, that re-syncs the time with the file system if the date there is newer than the binder modification date. I’ll put it on the list for consideration.
I personally would not put anything inside Scrivener’s project folder (or the package as it will be seen on the Mac). It won’t hurt anything (we specifically have code to ignore the top level folder because of the inclination for Windows users to mess with putting things in there), but I wouldn’t consider it good practice either. There’s nothing wrong with a sibling folder alongside the main project folder for this kind of stuff. And of course for Mac users, that see a project as a file without running a special contextual menu command, it would not be efficient to use this as a storage area.
The difference is that by doing it the way I did, you can use Scrivener’s backup to backup that as well.
Else, if the file is outside of the project folder, a Scrivener backup doesn’t include it.
Therefor, if you want to backup that other app file, and the only way to have incremental versions is through a save-as (in the other app – whichever it is), then the Scrivener project link(s) need to be constantly updated. Which was the OP issue.
Is there a better way?
(I personally never had any issue with doing things like that. Windows.)
[EDIT] I just ran a test: I dropped a scapple file into my binder. Then did a backup of the project: can’t find the scapple file anywhere in that backup. (?)
Yeah, I understand the rationale, but it really doesn’t make sense for a Mac user to do things that way given the high level of friction there is to digging into “packages”, and the understandable hesitancy toward doing so, as the contents of these are meant to be entirely managed by the software that works with them.
- If you want the resource to get backed up with the project, that’s what regular import is for.
- If you don’t want it backed up, that’s what alias/research links are for.
Like I say, we specifically added code to reduce management in the top level folder (if you try this in other areas you’ll probably encounter recovery routines meant to repair projects damaged by sync). So it’s not a big risk, but personally I wouldn’t because I know that the whole “.scriv” folder downward is meant to be managed by the software. It is a file format, even if it uses multiple files to store itself, and so I would no more do that than I would decompress a .docx file and put my own stuff in there, compress it, and then work on it in Word. The contents of the .docx file is Word’s to manage, and even if doing that doesn’t actually break anything, it’s considerably less safe than staying out of the areas software automatically manage.
I don’t even know if this is what the user is asking about though. They seem to be wanting modification dates to update in the Metadata inspector pane, and other areas where the date would be shown.
Whether the item is backed up is something else entirely.
You mean I would then get the same result ?
Or does it clone the file on import, then having to use that new copy of the file in the third party app ?
(Which would again force the user to go into the package just the same, no?)
I believe my complaint was misworded and caused confusion and misunuderstanding.
What I want is to be able to have a Research folder in a Scrivener Project (for example) and in this Research folder add an “Existing File…” Using that command add an existing Scapple file to that Rersearch folder by dragging and dropping… so far so good, yes?
Then, I want to be able to continue to work on that same file in Scabble (changes, updates, etc.) and have these automatically reflected in the view of the file when I go to that entry in the Scrivener Project’s Research folder. This is not what happens, only a snapshot is saved in the Scrivener Project.
Okay, in that case the user manual reference I pointed you to should help with that. You definitely can load any kind of “research” (basically anything that isn’t text) file out of the binder and into a native editor for that format, and when you save and return to Scrivener, click the Refresh button to see the changes, if there is support for previewing the content of the file.
As noted, the main difference between fully importing and linking is whether the file is copied into the project itself, where it will now transfer to other systems if you copy the project, and get backed up with it on a regular basis. Otherwise, functionally, linked files and fully imported files have nearly identical capabilities.
OK!
Here is an insight for everyone.
Yes, section 8.1.3 in the manual is helpful, but glosses over one imoportant fact… before making changes in a linked file, you must open it via Scivener commands into the native app. Opening a file and editing by just opening the file from its saved directory directly into its native app will allow changes (of course) but these will not be reflected in any way into the Scrivener Project. The user MUST open any linked file they wish to make edits in via the methodology stated in 8.1.3. (for example: my Scabble file “timeline” is saved as an Existing File… in the Research folder of my Scrivener Project. If I open this file in Scabble directly and change it, these edits are not reflected in the Scivener linked file. BUT, if I use the open command via Scrivener (8.1.3) and then edit in Scabble and save, then “RELOAD” (not REFRESH) the file, the changes are reflected in Scrivener.
Personally, I would then only link to the Scapple file :
and view the file inside Scapple by clicking the link.
Why bother with a refresh/reload and all that ?
If you get a new idea looking at it, you’ve got the file right there, edit-ready.
Vincent,
Not sure I follow you and the term “link” you use. I only see linking to URLs or other parts of a doc, not an external file.
Just drag your Scapple file in the research folder, or on a document, in the editor.
That’ll create a link.
Clicking that link will open that file in Scapple.
If I drag a file into the Research folder it saves a snapshot file, and that is the one that must be edited to have changes reflect in Scrivener.
Ah! Now I see in section 9.2 how to use links. I will check it out and get back.
I see.
That’s not what the Windows version does for me.
But then, you may want to create a new blank document, and drag the file to it (in the editor). That should create a link that will open Scapple, with the file loaded.
You just won’t likely get any visual cue. No Scapple icon or screenshot.
Just the file’s name. Like this:
(A_Scapple_File is my file’s name.)
Note that when you drag a file to the research folder, you are actually importing the file. It is no longer the original file. Not to be confused if you want to open it directly from within your third party app. Best then to use your Scrivener project as the “mother project” and only access other stuff through it.
I feel there is something still not being communicated well enough.
That’s not how it works though. There is in fact no difference between double-clicking on the original file in Finder, or using the shortcut/button in the Scrivener editor. Both route through the main operating system’s method for opening files. You’re basically saying one should not use aliases to load files, but always use the original file to double-click on in Finder, because that’s 100% of what we’re talking about here in terms of technology. Scrivener isn’t reinventing any wheels. There is a literal Finder Alias in your project that points to the original, and you load that in Scrivener it loads the original file, just like an alias would anywhere else. And just like an alias in Finder, if you edit the original and then open via the alias later, you will not get a “snapshot” or a version of the file that existed in the past. The following is not possible:
Opening a file and editing by just opening the file from its saved directory directly into its native app will allow changes (of course) but these will not be reflected in any way into the Scrivener Project.
So it might help to, in a very detailed fashion, explain how you are getting this result, from the very start to the very finish. I mean to say, start with how you import to begin with, and go through each button and menu command, each click in the binder, whatever you are doing to come to the conclusion that the alias in Scrivener is pointing to anything other than the original document you just edited.
I would say it is pretty clear.
The imported file is not the one that was afterwards opened (and edited) through Scapple.
If that is the case : that is exactly why I say that once using import, one should use the Scrivener project as the “mother project” and open stuff for editing in third party apps only through Scrivener’s project.
You’re talking about something else entirely though. We can speculate forever on what is going on, but a simple checklist from the OP would clear up the process, or reveal a bug. I doubt there is one though since loading a file via an alias or shortcut does not and cannot magically spawn copies of the file that become “snapshots” divorced from the original. That would defeat the entire purpose of linking to original file (which is how they described working). If they aren’t actually linking that’s another matter—again something that would be made clear with a detailed checklist.