Forgetful Fullscreen Settings

I am definitely seeing occasions where Scrivener is just forgetting my fullscreen settings (the one’s you set when in fullscreen mode).

For example, today ALL of my projects are reverted back to default fullscreen settings.

On other days, I have had some vague sense that some of my projects had had their fullscreen settings reverted to default, but today confirms my suspicion, since every one of them has been reverted to default.

System: Powerbook G4, OS X.4.8 Tiger, Scrivener 1.0 (demo-mode).

Settings known to be effected: Text Scale, Page Width, Background Fade.

What I was Doing: I began the day by duplicating a .scriv project file which I was going to set up for a different purpose. Fullscreen in the dup’ed project came up default. I set my preferred settings. But when I checked other projects, it appeared that all were reverted.

Hope this report helps.

Thanks,
GR

Did you move or rename any of your files? These settings - like window frame and so forth - are stored under the path of the project itself, so the .scriv file is renamed or moved, the settings are lost. I know this may seem a little awkward at first, but it is the standard Cocoa way of doing things, as it allows you to have different settings for the same file on different computers.

All the best,
Keith

Keith,

Yes, in that case, I think moving/renaming of the project files would explain what I am seeing today–as well as the onesie cases I had noticed earlier, too.

So, as I now understand it, I should expect to be resetting my fullscreen settings whenever I i) start a new project, ii) duplicate a project, iii) move a project file, iv) rename a project file, or v) rename a folder anywhere on the path to a project.

I am hard-pressed to think this a happy tradeoff for the feature you mention, but maybe that is because I expect to do the above sorts of things a lot more often than I expect to want to work on my projects on multiple computers. I also can’t help but think there must be a happier way of getting the feature you want. Moving documents or changing file/folder names should never undo one’s settings.

In any event, it is certainly helpful to know what behavior to expect. I will earnestly try to get over my expectations on this point and see what happens.

Now, I know you will not count this issue as a bug, but you have to allow that it also isn’t a feature. :slight_smile: It is at best an unhappy side-effect of your implementation of a feature. As such, I hope it will get further consideration when you work more on this program.

Thanks again for your ready reply.

Best,
Greg

p.s. My bid: store these settings in the scriv pkg but index each occurance to the machine (not path). That way you get per-project, per-machine settings but that also stay put through the kinds of changes above.

p.p.s. Lest you think me grumpy: I continue to be impressed with Scrivener and discover features and ways of working which add to my appreciation of what you have done here. E.g. the thoughtful inclusion of MultiMarkdown makes this app useful to me in an unlooked for area.

Hi Greg,

When I implemented these features, I just did everything the bog-standard way of doing it. There is a good case for this: if settings are stored inside a project, when you move that project to another machine you could easily end up, for instance, with a window way to big for the screen. Like I say, this is just the standard way of doing things.

But, of course, “standard” isn’t always the same as “best”. Others have made similar complaints, and I have already added this to my list of things to address in the future.

Implementing this in a different way isn’t exactly difficult so much as incredibly - and tediously - time consuming. There are so many areas of Scrivener that require state-saving, that changing it would mean changing hundreds of lines of code after figuring out a different system. For certain things (such as saving window size and outline expanded/collapsed states, it would even mean my having to come up with my own way of doing things that the Apple frameworks currently do for me automatically. So I hope you understand that whilst I agree that this is something I should take another look at in the future, it may be 1.5 or after before I can face the job. :slight_smile:

All the best,
Keith