Feature request: on Mac, implement standard multi-document behavior

[neilweinstock]

This request applies to Mac only, because it's a much clearer situation than on Windows (I'm unsure about Linux). Frankly, I would want this behavior no matter what platform I was working on, but only the Mac really standardizes this behavior.

On the Mac, an app that supports multiple open documents (such as OR) is expected to behave as follows:

1. Remain running even when all document windows are closed

2. If all windows are closed, and the app is activated from background -> foreground (e.g. by clicking the icon in the dock), there are two options:
   a) Open the file chooser
   b) Open a new blank document

Implementing this behavior in OR would make it much friendlier on the Mac.

Discussion
Regarding number 1:
Current behavior is quite frustrating. Usually, I'm only working on a single rocket at at time. Therefore, I want to close one rocket before opening the next. Right now, that closes OR, and I swear at it every single time, because then I have to re-open OR (which takes a while using the packaged version), then open the file I want to view, then close the window that was open previously. Over and over this repeats. By letting the app stay open after the last window is closed (again, standard Mac behavior), I can do what makes most sense: close one app, then open another.

To save my sanity, what I try to do nowadays is keep a garbage window always open and made as small as possible and tucked into a corner of the screen, so the program won't close. This is kind of ridiculous.

Regarding number 2:
Either one of these is acceptable I think, but in my own usage I am much more likely to want to open an existing file than create a new one. So if it were up to me, I would choose to see the file open dialog whenever either (a) the app is first opened and there isn't a last-open file to open, or (b) app is brought to foreground and there are no windows open. If what you actually want is a new rocket, then you dismiss the file dialog (app stays running!) and then File -> New.

The best modification of all is if you can also have a "Create new rocket" button added to the File Open dialog, so right there you have the choice of how to proceed. This behavior is, regrettably, much less common, despite being ideal. I don't know how difficult it is to implement, though. It is nice but not required.

[SiboVG]

1. Can confirm that I have to be prudent to not close all OR windows because of the Mac habit that your program still remains active after you've closed all windows
2. I find it more logical to open a new blank document (2b), as this is the same behavior that you get when launching OR. So as not to break with the normal OR launch strategy, I would go for option 2b and not 2a. That would be more impractical for your use case @neilweinstock, but IMO option 2b is a more logical choice.

[neilweinstock]

This is the part where I argue that launching a blank document when you launch OR is and has always been wrong. :)

Opening an existing design is a much more likely choice than starting a new one, almost always for almost everyone on all platforms.

[SiboVG]

This is the part where I argue that launching a blank document when you launch OR is and has always been wrong. :)

I was afraid this was gonna be the response 😉 well I'm not a daily user of OR, so I can't vouch for which way is the best for OR, but I can understand that you would want it this way.

If we were to change OR's launch behavior, I would opt to do a little bit more work and instead of just opening a File dialog, I would implement a home screen like you see in a lot of major programs (Microsoft Word, Adobe products...), where you have an overview of your recent project, and one-click away buttons for creating a new project or opening a project.

[neilweinstock]

Happy to oblige. :)

I have mixed feelings about those home screens in other apps. I'm not really opposed to them, but don't necessarily love them either. I suspect that doing something like that would be more effort and more contentious regarding the design than my proposal, which would make it less likely to ever get done.

This is all for future release so just friendly debate right now.

[hcraigmiller]

As to the application of the foregoing in Windows, most programs allow you to close all of the files without closing the program (a small "X" below the big program closing "X".

Functionally. in Windows, this would be the same as the Mac behavior described by @neilweinstock: "If all windows are closed, and the app is activated from background -> foreground".

In this state, comparing what would be expected in OpenRocket as to most Windows programs, the screen would be blank below the File, Edit, Tools, and Help selections (all of the design files are closed). And, when brought forward, it remains in this state, neither opening the file selector nor a new file.

Food for thought.

[SiboVG]

Well I hope that future Sibo has the time and motivation to implement a home screen because I do see the advantage of having one :) Namely needing less clicks to get where you want, and a more user-universal approach. With the home screen with one-click you would be able to go to a recent project, create a blank project or navigate to a new project. This also ensures that you're not "enforcing" people that like the blank project by default to switch to a File dialog by default, so it's more general for different kinds of users.

But as you mentioned, it requires more work yeah...

[hcraigmiller]

I like present Sibo's motivation and commitment.

[SiboVG]

I like present Sibo's motivation and commitment.

[JoePfeiffer]

Hopefully these are things that will be controllable from the preferences.

1. I am definitely in the camp that prefers to see the last rocket I was working on come up when I start OR. Programs that open into some sort of home screen and require me to take an extra step to get to work range from "unobtrusive and so not horrible" to "obnoxious".

2. When I open a new window, having the choices of "New" (to create a new design) or "Open recent..." to give me a choice of other designs to open seems very natural.

3. I'm surprised to learn startup time on other platforms is long enough there's an interest in keeping the process around when all the windows are closed. Maybe it's sloppy coding, but it seems like programs that do that on my Linux machine end up using more and more resources until I eventually have to kill them.

[neilweinstock]

I'll have further comment on what Craig wrote above, but first a quick response to Joe:

Hopefully these are things that will be controllable from the preferences.

Preferences are fine. Well-chosen default behavior is better.

1. I am definitely in the camp that prefers to see the last rocket I was working on come up when I start OR.

I am too, and I have this preference set. But sometimes I don't want to work on the same rocket. So OR opens, and I get the old ("wrong") rocket opened up. So, I do the natural thing and close that rocket. What happens? OR closes. So I grumble and re-open OR, and guess what? The same rocket opens up again. Lather rinse repeat. Usually on the second try I will remember that I must open the new rocket before closing the old one.

2. When I open a new window, having the choices of "New" (to create a new design) or "Open recent..." to give me a choice of other designs to open seems very natural.

I don't think this is necessary, but I certainly wouldn't object to it. This option would apply to two cases: (1) when you first start up the program, and you don't have "open last rocket" enabled in prefs, or (2) you bring the app to the foreground on the Mac, and there are currently no open windows.

3. I'm surprised to learn startup time on other platforms is long enough there's an interest in keeping the process around when all the windows are closed. Maybe it's sloppy coding, but it seems like programs that do that on my Linux machine end up using more and more resources until I eventually have to kill them.

The difference is possibly the behavior of the packaged app vs. the raw .jar file. With the packaged app, a full JVM must start up from scratch each time, and on my Windows and Mac machines it takes several seconds. This is one of the two big disadvantages of the packaged app (the other one being download size).

I want the program to remain open when I close the last window because that is multi-document apps are supposed to behave on the Mac. Single-document apps have a choice; they can either close or remain open when their window is closed. But OR is a multi-document app.

[hcraigmiller]

Looks like users are asking about this again.

The use of the "close" and "quit" terminology in applications seems consistent across major software developers. The term "close" is used when the user wants to close the currently active project, leaving the application open; and the term "quit" is used when the user wants to stop using of the application.

Applied to OpenRocket...

• The desired "close" behavior would be to close the current project, but not quit the application. If there is more than one open project, when the currently active project is closed the next most recently active project would become the currently active project. If there is no other open project, then OpenRocket would remain open, but the panes would all be blank, and the user would have to select new or open before continuing. [This is NOT how OpenRocket currently functions.]
• With one or more projects open, the desired "quit" behavior would be to close all of the projects, and to quit the application. [This is how OpenRocket currently functions.]

As I believe @neilweinstock has expressed, this behavior should be consistent across platforms, Linux, Mac, and Windows.

[neilweinstock]

Looks like users are asking about this again.

The use of the "close" and "quit" terminology in applications seems consistent across major software developers. The term "close" is used when the user wants to close the currently active project, leaving the application open; and the term "quit" is used when the user wants to stop using of the application.

I don't believe there is any question about the distinction between "close window" and "quit app". The current File menu in OR is fine in this regard. The question is what to do when the last window (or project) is closed.

Applied to OpenRocket...

• The desired "close" behavior would be to close the current project, but not quit the application. If there is more than one open project, when the currently active project is closed the next most recently active project would become the currently active project. If there is no other open project, then OpenRocket would remain open, but the panes would all be blank, and the user would have to select new or open before continuing. [This is NOT how OpenRocket currently functions.]

That's not quite standard Mac behavior, which is: if you close the last window, the app stays open with no windows. If you want a new window, you can use the File menu for a new design or open an existing one.

If you switch to another app, and then switch back to it (via its dock icon) then the app should at that point either create a blank new window or active that File->Open dialog. Either is acceptable.

That is the desired behavior on the Mac.

As I believe @neilweinstock has expressed, this behavior should be consistent across platforms, Linux, Mac, and Windows.

The standard Mac behavior does not apply to Windows or Linux (I think), because there is no concept of having an app open without a window. In Windows, usually, closing the last window closes the app. Not sure about Linux, or if it's even consistent there.

Possibly Windows or Linux could operate the way Craig has described above.

[JoePfeiffer]

• The desired "close" behavior would be to close the current project, but not quit the application. If there is more than one open project, when the currently active project is closed the next most recently active project would become the currently active project. If there is no other open project, then OpenRocket would remain open, but the panes would all be blank, and the user would have to select new or open before continuing. [This is NOT how OpenRocket currently functions.]

The standard Mac behavior does not apply to Windows or Linux (I think), because there is no concept of having an app open without a window. In Windows, usually, closing the last window closes the app. Not sure about Linux, or if it's even consistent there.

As with so much, Linux is not consistent here. Personally, I'm most comfortable with applications that shut down when their last window/project is closed, but there are some that act as above. OpenRocket does have a concept of running with no current design (it's the status when started when the "Open last design file on startup" checkbox is not checked), so it ought to be possible to make it behave this way without too much effort -- but I think we have higher priority issues on our plate.