I did search for this but couldn’t find it anywhere (went back 3 search result pages).
I love Scrivener and I use it on Mac and iOS (two devices).
One thing I am missing though is to be able to link and/or reference characters or documents in another project.
I know of the import function, and that it lets me import another Scrivener project, but if I make changes in either end, they don’t sync up; basically I have duplicated the other project in to the new project, but they are completely detached from each other. What I’d like is basically to have the option to “link” one project with another, and that I thereby can link and update to documents or character sheets which then update the original project as well.
The stuff I’m working on right now has a base set of documents (which could be one Scrivener project), and then several episodes that use the characters, settings, environments etc. I would like to be able to split those episodes out to separate projects, whilst still being able to update the base project, either directly, or from the episodes (i.e. “once”, not “many times”).
The current alternative is to create one gargantuan project (it is currently 800mb) which takes forever and ever to sync via Dropbox, especially to/from my iOS devices, and obviously is a pain when out-and-about. If I was able to split them up and still retain the possibility to reference/link between them I would only ever sync the project where there had been changes, which would make syncing a lot more efficient.
That is my wish.
The alternative I guess would be to have a different way of syncing altogether, and only sync the files/pages that actually have changed, but I would guess that would require even more work.
Have a look at §8.5.6, External Links, starting on page 100 of the user manual PDF. It is possible to create a URL to any item within your Binder and thus create links in any context where links can exist which easily open specific resources within your projects. With other programs you’d copy the link and paste it, but between two projects in Scrivener it is even easier: just drag the item from one binder into the other project’s References pane, in the Inspector (either Project References or Document References), and of course since it is a URL, you can create hyperlinks in your text documents pointing to other project’s resources too. As I say, anything that lets you make a link within it will work.
It’s worth noting that for numerous reasons of technical impossibility, this is not something you can do between systems (well, identically configured Macs aside). They are static full-path links to a specific project on your disk and a resource within them. iOS doesn’t even have such a notion itself as “files and folders”, nor Reference for that matter.
One final thing, a word of caution, you might want to hold off on going too crazy with the technique right now. The URL formation will be changing in the future by necessity, a future not too far off. So make use of it where convenient, but not as a permanent archival solution quite yet.
Well, we already do that to be clear. The initial sync is the only one that should require every single document to be downloaded or uploaded. However extremely large projects will have a certain degree of overhead by necessity. If there are 10,000 files that need to be checked for syncing, just the mere act of checking which ones should be uploaded or downloaded will be time consuming.
Ah, excellent. That is close to what I’m aiming for. Yes, indeed I was already using links to external sources, as in properly external (web sites, sounds etc).
Right. It is probably tricky on iOS, but can be worked around. The folders you (as a developer) can control on iOS are the ones bound to your developer account (com.literatureandlatte.scrivener or whatever you could have), and which your app(s) have created. If you structure your app(s) cunningly you will actually know the root folder and its underlying structure (as you have created it). You then can reference files, and have your apps using the same files. You can’t reach other apps files/folders, nor can they reach yours (unless you build/provide an SDK or similar), but still, for the purposes of my original question, it would still be a possible route to consider. If you (or the relevant people at your end) would like examples, this is a decent start according to my developer mate: developer.apple.com/reference/f … yapplicati
Ah, right, well I wasn’t planning of constructing my life around it, but still good to know. Right now I am mainly interested in only doing character/place descriptions once, in one project, and then forever after linking to those characters/places from other projects.
Oh? Is that how Dropbox treats the .scriv files too? I had a feeling it (Dropbox) tries to sync the whole thing. 10-15 minutes sync times are not unusual for .scriv files that are between 500 - 800 mb, and that is in one direction. In all honesty it has felt like Dropbox has a network cap or something too, with my connection (1 GB connection) it should be a lot quicker, then again I had to do a full restore on one of my Macs the other week, and downloading 100 gb from Dropbox took 9 hours when it should have taken 9 minutes.
Anyways, thanks for the reply and even more thanks for great software. I love it, and this was just a small niggle I was wondering about.
I had to dig to find the link, but this is the explanation of how dropbox syncs changes in individual files: dropbox.com/help/8
What you’re describing sounds like the very first time the project syncs, and so it will take as long as it would normally take to upload 500-800 mb to dropbox.com. Are you experiencing these long sync times when you just write something in a single document in the binder?
BTW, if you find a project on your Mac and ctrl-click on it and choose the “Show Package Contents” option, you can see for yourself how a Scrivener project is just a bunch of folders and files, internally. Dropbox sees that it that way too, and so can sync just those parts that change, rather than the entire project.
Oh sure, I didn’t mean to make it sound impossible as a general theory, there are plenty of strategies, even including internally tracking projects by ID numbers rather than paths, but some of these methods come with their own but different drawbacks. What I meant is that, in the system as it stands right now, from feature set to addressing, is not conducive to making it possible. It’s just one of the downsides, I guess you could call it, of giving one full authority over how they manage their own work and not doing anything to try and “caretake” that aspect of organisation—at least on the Mac of course. On iOS we have no choice but to remove all of your choice and handle full management.
Under ordinary circumstances it shouldn’t, but the software should be noting for you on the progress screen how many files sync is currently working with. It will always be higher than the amount of items you’ve edited in the project (each index card is its own .txt file, notes, etc.), but using a rough estimate and tracking whether test edits only change a few and not hundreds, you should be able to gauge whether all is healthy. You did mention your route to Dropbox has seemed slow as of late, it may just be related to that. I’ve noticed it sometimes does seem to take forever to finish working even though my connection is quite good elsewhere.
There is capping done by Dropbox on the API side—what we have to use on iOS. On the Mac you of course use their own client and I have noticed it is much swifter in general than what they allow others to do. I don’t think it’s a bandwidth cap so much as a frequency cap. We do deliberately have to slow down uploads in particular in order to avoid getting a bunch of Dropbox errors that necessitate restarted the process (from where it stopped, at least).
Yes, it has been after initial sync, even when just a handful of (general and simple) text has been edited, in a large (counted in megabytes) project. The project does contain a couple of large PDF’s too, as research material, don’t know if that affects it in any way, but they (the pdf’s) haven’t changed, though my position (page) in them might have. I haven’t noticed the same slow sync when syncing other test projects (which admittedly, due to the nature of being test projects, only have a handful of files in total), and only total just over 1 mb.
I’ve only noticed the extreme sync times on iOS, but still on Wifi, with the one exception of the Mac backup-restore with re-sync of Dropbox mentioned (which wasn’t related to Scrivener per se).
I am currently trying to extract the text out of the PDF’s to look at the possibility of removing them altogether, and thus making the file size of the .scriv (a lot) smaller. Will see if that makes the sync quicker. The drawback there is obviously that PDF’s do have a couple of benefits (images, precise pixel-perfect layout, zoom and generally pretty and read-able) but as I mainly use them for searching in, and trying to find the search results in them, I might get it to work anyways. On that note I have noticed that searching for a term in multiple PDF’s (well, a project) only returns the names of the PDF’s containing that term. That could be fine and well, but if there are more than one mention of the term I’m on my own again, I can’t get a list of which pages within a PDF that search term appear on, I can only step forward (CMD-G) until I reach the instance I’m looking for, correct? Just checking, could very well be me being a newbie, I’m still learning the ropes of Scrivener.
We do have a tool for that. Select the PDF in the binder and use the Documents/Convert/Convert PDF file to Text. As noted in the warning, this is a non-reversible process, so backup the original accordingly. In my experience PDF has a bit a rough time converting to text, as the two formats could hardly be more different internally.
Now as for whether that would speed up sync, it’s unlikely, and shouldn’t be for any reason I can think of—certainly not for scrolling around, that isn’t a change to file itself but another meta-data file specifically for tracking that sort of stuff. But it will save a lot of space if there are many large PDFs in the projects, and they would be easier to annotate and work with, so there is that.
Right, as with systems like Spotlight, or searching for email in Mail, project search is a low granularity collector based on indexing. It gives you the resources that contain the data you are looking for, and from there one steps through phrases using some form of viewer or application—in our case you just hit Cmd-G from the search results list and you’re good to go in the other side of user interface.
If you need more, hit Ctrl-Cmd-O while viewing the PDF to load it in your preferred reader, or click the application button on the right-hand side of the PDF viewer footer bar. We aren’t exactly in the business of making PDF readers as well, and are thus limited to the basics provided by the system.
Whoa! That is great actually! As you say, not perfect, but having tested a couple of apps from AppStore with less-than-impressive results, this is better than most of them! Thanks, you just saved me many hours of copying/pasting!
