Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Close UG windows when main app window is closed #1360

Merged
merged 7 commits into from
Aug 9, 2023

Conversation

emlys
Copy link
Member

@emlys emlys commented Aug 1, 2023

Description

Fixes #1258

Also fixes a similar, mac-specific issue where the app could not be reopened after clicking the red traffic light button.

Checklist

  • Updated HISTORY.rst and link to any relevant issue (if these changes are user-facing)
  • Updated the user's guide (if needed)
  • Tested the affected models' UIs (if relevant)

@emlys emlys requested a review from davemfish August 1, 2023 20:23
@emlys emlys marked this pull request as ready for review August 1, 2023 20:23
Copy link
Contributor

@davemfish davemfish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@emlys , thanks for the new bug report in #1258 . I think that probably indicates a larger issue in our main process logic. Maybe the fact that much of the code in createWindow assumes that the application is starting up fresh and not already running.

What is your opinion about the right design for MacOS? I see at least 3 options:

  1. Stick to MacOS conventions: the red button closes the window but leaves the application running. In which case we need to resolve the above-mentioned bug to allow the window to re-open.
  2. Break convention by re-programming the red button to behave like the yellow button.
  3. Break convention by re-programming the red button to fully exit the application.

As a general principle I think there needs to be a pretty strong reason to break an OS convention. But I also don't see too much value in the conventional behavior, for the Workbench. I just worry that option 2 will surprise some people. And maybe option 3 would too, I'm not sure.

// On OS X it is common for applications and their menu bar
// to stay active until the user quits explicitly with Cmd + Q
event.preventDefault();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you describe the implications of this event.preventDefault()?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default behavior of the window-all-closed event is to quit the app, so the intent is to prevent quitting on macOS. You made me realize it makes more sense to write it this way:

  app.on('window-all-closed', (event) => {
    if (process.platform === 'darwin') {
      event.preventDefault();
    }
  });

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, thanks @emlys . I think the docs are slightly unclear here. One way to read it is that simply subscribing to this event already prevents the default behavior of quitting. And that seems like the way it was working previously, where closing the window did not quit on darwin.

With this configuration closing the window no longer quits the app on Windows. So that makes me think that subscribing to this event already prevents the default behavior. I think we can just revert this back to: ?

  app.on('window-all-closed', () => {
    // On OS X it is common for applications and their menu bar
    // to stay active until the user quits explicitly with Cmd + Q
    if (process.platform !== 'darwin') {
      app.quit();
    }
  });

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the window-all-closed handler might be unnecessary now, since on mac, we minimize the window instead of closing it. And it seems like we want the default behavior on Windows.

@@ -184,17 +195,20 @@ export function main() {
createWindow();
}
});
app.on('window-all-closed', async () => {
app.on('window-all-closed', async (event) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know it was already like this, but it looks like we do not need this to be async.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed!

workbench/src/main/main.js Show resolved Hide resolved
@emlys emlys requested a review from davemfish August 3, 2023 20:50
@@ -184,17 +195,19 @@ export function main() {
createWindow();
}
});
app.on('window-all-closed', async () => {
app.on('window-all-closed', (event) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this no longer quits the app on Windows

@emlys emlys requested a review from davemfish August 9, 2023 18:06
Copy link
Contributor

@davemfish davemfish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, thank you!

@davemfish davemfish merged commit f2af890 into natcap:main Aug 9, 2023
18 of 19 checks passed
@emlys emlys deleted the bugfix/1258 branch October 3, 2024 22:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cannot re-open Workbench after closing the main window, if a UG window is still open
2 participants