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

feat: 'will-move' event for windows. #14283

Merged
merged 3 commits into from Aug 28, 2018
Merged

feat: 'will-move' event for windows. #14283

merged 3 commits into from Aug 28, 2018

Conversation

sgd2z
Copy link
Contributor

@sgd2z sgd2z commented Aug 23, 2018

Description of Change

Added a "will-move" event to the BrowserWindow, similar to the "will-resize" event. Windows only.

Checklist
Release Notes

Notes: Added "will-move" event to the BrowserWindow.

@sgd2z sgd2z requested review from a team August 23, 2018 18:50
@welcome
Copy link

welcome bot commented Aug 23, 2018

💖 Thanks for opening this pull request! 💖

We use semantic commit messages to streamline the release process. Before your pull request can be merged, you should update your pull request title to start with a semantic prefix.

Examples of commit messages with semantic prefixes:

  • fix: don't overwrite prevent_default if default wasn't prevented
  • feat: add app.isPackaged() method
  • docs: app.isDefaultProtocolClient is now available on Linux

Things that will help get your PR across the finish line:

  • Follow the JavaScript, C++, and Python coding style.
  • Run npm run lint locally to catch formatting errors earlier.
  • Document any user-facing changes you've made following the documentation styleguide.
  • Include tests when adding/changing behavior.
  • Include screenshots and animated GIFs whenever possible.

We get a lot of pull requests on this repo, so please be patient and we will get back to you as soon as we can.

Copy link
Member

@ckerr ckerr left a comment

Choose a reason for hiding this comment

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

Good start. Looks like a reasonable idea.

@@ -1,1532 +1,1543 @@
# BrowserWindow
Copy link
Member

Choose a reason for hiding this comment

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

A 3000 line diff in the docs...? 😄

Please fix these side-effects

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ugh, will do, must be whitespace. Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ckerr fixed

::GetWindowRect(GetAcceleratedWidget(),
reinterpret_cast<RECT*>(l_param));
return true;
Copy link
Member

Choose a reason for hiding this comment

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

What does the changed return value do here?

For the most part this patch seems symmetrical with the WM_SIZING handler except that it always returns false.

Copy link
Contributor Author

@sgd2z sgd2z Aug 23, 2018

Choose a reason for hiding this comment

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

Without the change in value, frameless windows can still be moved with -webkit-app-region drag and neither !movable nor preventdefault work

Copy link
Member

Choose a reason for hiding this comment

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

Makes sense. Could you add a short comment in the code to this effect?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ckerr done

@sgd2z
Copy link
Contributor Author

sgd2z commented Aug 27, 2018

Any word on this? Is there anything else I need to do? Also, what would it take to get "will-resize" and this "will-move" into 3.0.X? We would like to deliver a product that uses stable electron as opposed to something that uses a 4.0 nightly. Thanks!

@ckerr ckerr added the semver/minor backwards-compatible functionality label Aug 28, 2018
Copy link
Member

@ckerr ckerr left a comment

Choose a reason for hiding this comment

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

Thanks for the changes!

@ckerr
Copy link
Member

ckerr commented Aug 28, 2018

Also, what would it take to get "will-resize" and this "will-move" into 3.0.X? We would like to deliver a product that uses stable electron as opposed to something that uses a 4.0 nightly. Thanks!

That would require a change in Electron's versioning policy. The feature set for 3.0.0 was frozen at 3.0.0-beta.1 and so only bug fixes and security fixes are allowed in the 3-0-x line.

After this feature lands in master, I'd expect to see it in either 3.1.0 or 4.0.0, whichever comes first.

@ckerr ckerr merged commit afdb6c5 into electron:master Aug 28, 2018
@release-clerk
Copy link

release-clerk bot commented Aug 28, 2018

Release Notes Persisted

Added "will-move" event to the BrowserWindow.

@welcome
Copy link

welcome bot commented Aug 28, 2018

Congrats on merging your first pull request! 🎉🎉🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
semver/minor backwards-compatible functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants