I normally run under a standard user account rather than an admin account. I downloaded Scrivener 1.03 in the admin account to install it in the Applications folder, then switched back to the standard user account. When I try to start the tutorial, I receive the following message:
Tutorial not found
There was a problem opening the tutorial. If this problem persists, try re-installing Scrivener.
When I switch back to the admin account, however, the tutorial opens just fine. (Other functionality–preferences, Help menu, etc.–seems fine in the standard account, although having only just installed it and not done the tutorial yet, I can’t vouch for all of it!)
Until this is fixed, go to the Applications folder, and right-click on Scrivener. Choose “Show Package Contents” and navigate to Contents/Resources. You’ll find a file called Tutorial.scriv, in that directory. Copy it out into your Documents folder, or wherever else you’d like. Now you should be able to open it by double-clicking on the project.
Sorry, what do you mean, “until this is fixed”? There is no bug here. When you click on “Tutorial”, Scrivener uses the standard Apple methods for launching the tutorial in Scrivener. Seems to be a problem with your account, maybe?
(You know, the tutorial used to be included on the DMG with instructions on the readme about how you needed to drag it to your hard drive, otherwise it wouldn’t open. Every day I would receive e-mails from people who didn’t read the readme, didn’t drag it to the hard drive, and who thus couldn’t open it. So, I moved the tutorial into the program itself. Now I receive e-mails every day from users who haven’t dragged Scrivener into their Applications folder. You can’t win. Not that this applies in this case.)
Is this a permissions problem, or what? I don’t really know what Scrivener could possibly be doing wrong here.
It’s probably a permissions issue. To run an application from a user account, install the app while IN the user account. Admin accounts are mainly used for trouble-shooting.
Well, I phrased it that way because all non-admin users cannot currently open the tutorial, and the fix is extremely simple. Just go into the bundle and set the read/write permissions to full for everyone on the tutorial file (and maybe use the enclosing items function, too). I just did it on my installation, and fixed the problem.
Is that right? No non-admin users can open the tutorial? I think it must be because Scrivener is installed in another user account… Weird. Like I say, the tutorial is opened using standard Apple methods, but because they return a path to something inside a bundle, that must cause problems. Weird if they return a local path, though. Will look into it.
Thanks,
Keith
Here is the setup I tested it on. Scrivener.app is located in /Applications, available and visible to all accounts. Permissions on the Tutorial.scriv file were drwxr-x-r-x. From the non-admin account, if I select Tutorial from the Help menu, I get the error message stating the file could not be found (which is of course not entirely accurate). Back in the admin account, I changed the permissions to drwxrwxrwx, logged back into non-admin, and the tutorial opened up without a problem.
So the problem is not what method you are using to open the file, that is all standard and good. It is simply that a non-adminstrative account does not, by default, have the right to modify the contents of globally available applications (and for good reason). Since opening a project in Scrivener requires the ability to modify the contents of it–poof–weird error is thrown.
So do you think it is the wording of the error that needs changing? What would be a better wording? Something like, “The tutorial could not be opened. You may be opening Scrivener from a volume to which you do not have write permissions.” or some such?
Best,
Keith
I’ve just seen I clicked “New Topic” instead of “Post reply” a few moments ago, and didn’t notice! So the first post starting the thread “A similar but not identical issue …” or some such wording, was actually intended to go here!
My initial reaction was to suggest just that the permissions are changed on the document. However (and echoing xiamenese), I then thought of public computer labs and their desire to keep the Applications folder locked.
So let me add a 4th possibility: create the tutorial in user space the first time Scrivener is run, perhaps via the 3rd mechanism AmberV suggests or alternatively without user interaction to choose the location (I don’t favor that one…). I believe this is the strategy most applications use to store user space documents, although many hide them in the library.
I have seen the third mechanism employed in other applications, and it has never thrown me off or frustrated me. You choose where the file goes (I hate when programs think they know where I want files to go ahem, Microsoft, and you can start using the project instantly once it is saved. I had thought of the permissions problem in public environments, and though I added an adjunct to that effect, but I must have forgotten to.
Right, I think I was supporting the use of this mechanism in case my wording was vague – what I don’t like is what Microsoft does. What I was trying to suggest (but inflicted with the results of several days without a good night’s sleep ;-( ) was that your suggested mechanism is applied to the Tutorial automatically the first time Scrivener is run.
Not that this applies in this case.)
So the first post starting the thread “A similar but not identical issue …” or some such wording, was actually intended to go here!