Scrivener exhibits some (IMO, obviously) less than ideal behavior regarding closing projects and closing the program itself. These are especially apparent when working with more than one Project (consecutively).
My issue:
I finish my work on a project and go to close the project and then open up another. If I close the project (going to File->Close Project), then Scrivener closes completely. That’s not great. But there’s a work-around: I can choose in the options to show the ‘New Project’ window when no projects are open. So fine, choosing that option solves that problem. Only–it introduces another:
As I’m working on my subsequent project, whenever I close the program (by clicking the red X in the top right OR by going to the File menu and quitting), the ‘New Project’ window opens. But I didn’t want to close the project, I wanted to close the program. I understand if the code closes the project and then the program, but I, as a user, perceive a difference between the two.
My suggestion:
These two functions need to be separated more clearly. There are lots of different approaches to this issue, and I don’t know which one’s necessarily ‘right’ for Scrivener. I’d settle for not having that ‘New Project’ window open up when I quit the program.
Isn’t that the same behavior for all windows programs? in looking at my win 7 system the only things that “stay open” are sys-tray apps like IM, notes, etc.
I think this is more OS related than app related for non-service level apps.
Not really Jayson. I’m not suggesting Scrivener stay open at all times, I’m differentiating between closing a document (project) and closing the program. Like I said, there’s a lot of different solutions to this problem.
For example, in Microsoft Word, each document opens as a separate window. Even so, if you close the last document (without exiting), it leaves an empty window open.
In Adobe Photoshop, each image opens as a tab by default. Closing all the tabs doesn’t close the program. (as compared to say, Firefox or Chrome, where closing all the tabs does close the program).
OSX approaches this issue in a totally different way: the top menubar represents the program, the windows represent documents. You (as far as I know) can’t close the program at all from the window.
All of these programs distinguish between closing a document, and closing the program. Not all programs do, but those that don’t end up with some irritating use-cases.
I haven’t seen that behavior since word 2003 but that could be an option setting that is controlled corporately. I do see that in excel though, which I think shows something to note…
I think the variation that you are describing is “program window” based apps (Adobe, Excel) vs “project window” based apps (scrivener, word on my system). I’m thinking that it is the fact that in windows the app “is the window” is conflicting with the Mac based “the window is a project and the app is independent” philosophy. Without fundamentally altering the windows interface to be completely independent of the mac version, I’m not sure how Lee could resolve this conflict.
I agree with the above user’s assessment. This is not how Win-based programs treat closing projects/closing programs. Scriv’s approach here is non-standard to the OS. I think it can be hard to avoid the “Mac mindset” when working on Win products. But it remains that anyone using a Win-based program is not in that mindset.
Part of the problem lies with what to do when you open the program directly (not by double-clicking on the project file). With Word, it will open a blank document, which is just a potential document. You can go to your recent documents list and open another one, or just close that blank Word window, and you don’t end up with any clutter.
Scrivener can’t just create an entire new project without writing to the disk. It’s built into it’s core functionality that it will continually save your work as you write, and it remains snappy by only opening the sub-documents you are working on instead of an entire 100,000 words of your manuscript. That’s why you have to choose a name and a location for your project before you start writing; Scrivener does not work solely in memory, but relies on the file system to keep your data safe. In that way, it goes far beyond any Mac UI model.
If you want to exit scrivener entirely while one or more projects is open, File->Exit will do that, while having “Show start panel with there are no project open” checked in the Tools->Options->General tab will do just that when you close your project (File->Close Project or the red X button on the window).
Why not? And by that I mean that the feedback I’m providing is that as a user I expect the red X of the last (only) window to close the program, not the project. It’s up to Lee & the team to decide whether they think that’s the typical case or if I’m the exception.
When I found that the File->Quit does in fact do what I want it to (which you graciously pointed out), I tried to set up a keyboard shortcut for it, and discovered a bit more murkyness. The default keyboard shortcut for closing a project? CTRL-F4. The default keyboard shortcut for closing the program? There isn’t one listed. And I can’t assign one in preferences (Quit or Exit doesn’t show up in the File portion of the keyboard section of the preferences pane). It’s part of the windows idiom that ALT-F4 quits a program–so I gave it a try. It triggers the same chain of events as the red X: project closes, new project opens up.
I think I’m missing something: How can you have it both ways? Pressing the red X on the last project window can only do one of the following:
Close the project, and pop up a start panel so you can create a new project or open an existing one.
Close Scrivener completely.
It cannot do both of those simultaneously, but you, as a user, can decide which of the two reactions to pressing the X will occur. As I inferred earlier, just change the check box for “Show start panel when there are no projects open” in Tools->Options->General to be un-checked.
I think I misinterpreted what specifically you meant. I interpreted ‘Have it both ways’ as more of a general statement than a reference specifically to the red x.