Losing view settings

This has happened several times - I’ll go to the trouble of setting up the view settings I want - window position, section widths, background colors, etc. - then I’ll launch Scrivener and everything will go back to the default. Are these settings stored in each bundle, or are they in the prefs?

Kirk

The settings are per-project. The settings should be kept between sessions for each individual project, but if you create a new project, that will have the default window size etc.
Best,
Keith

Well, two problems then.

First, I’m losing them between sessions, without creating new projects.

Second, it would be a good idea to allow standard settings to be applied rather than using default settings for new projects. In my case - and perhaps for others - I want my views to be the same regardless of projects. I would think than any chages to the defaults in a specific project should be stored in the project, but otherwise, the defaults should be user-configurable.

Best,

Kirk

This has been brought up before, but is unlikely to change before 2.0, I’m afraid. It is standard for such programs to start new projects with a default size (Xcode for instance), especially seeing as Scrivener is designed for big projects where you aren’t creating new projects all the time.

As for losing settings between sessions - did you move the .scriv file? Settings are saved in the preferences by the project path. And before you tell me this is a bad way of doing things, go tell Apple. :slight_smile: This is just the standard way of saving such settings. If you didn’t move the project, I don’t know what to say - I’ve never seen such a problem.

Best,
Keith

No, I didn’t. Can’t you have a .plist file in the bundle?

I guess, then, the only way to have the settings I want is to take an existing project, copy it, then use the copy. (I’ll make a blank one.)

Kirk

It’s called a template … :slight_smile:

Mark

Templates don’t save view settings, though, I am afraid. As I have said elsewhere, this may change in the future - but probably not until 2.0. The trouble is that although the changes would be relatively trivial, there is no much code involved in state-saving that it is mindnumbing and would take a loooong time to reconfigure, and given that the current implementation is the standard way of doing things, changing it is low priority.
Best,
Keith

Interesting … templates … if kirkmc created a blank project with the settings he wants, saved it and then re-used that, the settings would be preserved; if he makes a template they are not. So if he makes that blank project, saves it, goes to Info on it in the Finder and chooses “Stationery Pad”, does that not do the same basically as making a template?

Oh, no, I’m with you … Scrivener projects are bundles, not files and you can’t turn a bundle into a Stationery Pad document. Hmm … :slight_smile:

Mark

Uh, I don’t think what kirkmc suggests will work either. All settings are based on project path, so if you copy a project, the path will be different, so the settings won’t stick…

I don’t know why you say this is an Apple thing. I’ve never had files from any other program change their view settings just because I’ve moved them to a different location…

Kirk

I’ve raised this before, and am glad to see it brought up again. It’s the one of the few things that bugs me about Scrivener, but as a journalist who opens a lot of new projects, it bugs me a lot. I’d hope to see it addressed before 2.0, but perhaps not if it interferes with Keith’s Booker winner. In the meantime, I’ve moved back to Mellel for short pieces, and fire up Scrivener if I’m going to be in the piece for a few days. And then the per-session settings break … these issues, and a few export niggles that I can’t rightly expect in a V.1 product, tarnish the Scr. halo slightly, but I remain dazzled by its lustre.

I agree, it’s more an annoyance than anything else, but enough of an annoyance that it’s a bother. :slight_smile:

Especially because yesterday it totally lost my settings, and I had to redo the color (I use a custom background color) and some other things, in addition to the window layout.

Kirk

Please take a look at the Cocoa documentation. The following methods may be enlightening:

-setAutosaveName:
-setFrameAutosaveName:

Also see:

cocoadev.com/index.pl?NSWind … Autosizing

Note the part that mentions that jcr from Apple recommends using NSDocument’s filename as the frame autosavename for NSWindow, which saves the window frame of a document-based app under the filename - i.e. Apple recommended behaviour.

Also see this from the Apple Cocoa documentation:

developer.apple.com/documentatio … ition.html

Note, especially:

[window setFrameAutosaveName:[window representedFilename]];  // Specify the autosave name for the window.

See how Apple recommend saving a window’s position by the -representedFilename? This is the path of the document file.

That is from the latest Apple Cocoa documentation. But perhaps you have inside information from Apple and you know of a new recommended way of saving window and view frames? Currently, though, all of the Cocoa methods built around saving view and window sizes and positions are based on saving them linked to the file name.

The alternative is to write my own system of saving such positions within the project bundle. But again, I stress - and I am not lying - Apple already provide a number of methods for saving such settings, but the drawback is that they are all saved agains the document name.

Please do check out the above links if you still don’t believe me.

Best,
Keith

Keith, I’m not a programmer, so that doesn’t do much for me.

How come I can open any Word document and it will be in the exact view that I had it in the last time I saved and closed it? I’m not talking about the position in x,y, but the entire layout - whether it’s page view, normal, the width, etc.

For example, when my wife sends me files from her laptop, they are the size she had them displayed on the laptop (I have a 20" screen so I have to make them bigger)…

Kirk

Because Word is programmed by Microsoft? Because every program is different? You asked why I blamed Apple. I gave you an answer. The fact is, that Scrivener uses Apple’s built-in Cocoa methods. I’m not saying these are perfect - they aren’t. But they are expedient.
Best,
Keith

Ever feel like the man who built the Ark, and now all the critters are shouting, “Make the door wider! taller! double-hinged!” instead of just getting on board?

Keith,

I wonder if one of the following might not be simple and worth doing in the interim to alleviate some frustration with this behavior of Scrivener.

  1. When Backup Project (w/o zipping) is chosen, save the settings of the new project in the prefs file, or 2) add an explicit Save-a-Copy item that does the same thing, or 3) make the defaults for the “lossy” settings user settable (heck, personally I would be happy if the defaults were just hackable–they appear to be hardcoded at this point–I told you I peeked :wink:).

As a temporary workaround while we await a more thoroughgoing resolution, probably (1) is better than (2).

From my own way of working with Scrivener so far, it seems to me that (3) would entirely address my own issue–since so far, I am really looking for basically /the same settings/ in outline and full screen–so if I had some control of the defaults… Seems like one of these could be a simple mod, but I am just guessing, of course.

Doing any of the above in the near term would give us some way to make projects that preserve all the settings. It would also enable give us a way to (in effect) rename or move projects in such a way as to preserve settings.

Best,
Greg

P.S. The lossy settings problem ranks as my number one dissatisfaction with Scrivener. It also seems a real stand-out in anomalous program behavior that renaming files or folders should wipe out settings. As such, I think /every/ new user is going to have a negative experience with it, have some level of annoyance because it frustrates standard expectations of usage on the Mac, and lots of them are going to feel that they are seeing a bug.

I think it is helpful to distinguish between

a) something’s being “an Apple thing” in the sense of being a behavior that results from the use of standard subroutines provided by Apple,

and

b) something’s being “an Apple thing” in the sense of being a standard program behavior on a Mac.

In this case what we have is and Apple thing in the sense of (a) but not (b).

But Keith is also saying that these two facts are related. The handy (a) facilities enable provision of all those nice project-wise settings, but result in some annoying non-(b) behavior. Thus, getting the project-wise goodies and having your (b) too, requires some serious work under the hood b/c you can’t just use the nice (a) facilities.

–Greg

P.S. My current list of “lossy” per-project settings: 1) full-screen mode settings (page width, zoom, background, etc.), 2) outline mode settings (column choices and their widths), 3) icon-tinting option. Changing project file name or names of enclosing folders or moving a project causes these per-project settings to reset to their defaults.

Please accept that this is not going to change in the near future, and nagging will not help. This is not a bug, the behaviour is observable in the trial, and the website and readme file make clear that no updates are promised other than bug fixes.
Best,
Keith

I am duly chastised.

Best,
Greg