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

Require setting the activation policy on the event loop #1922

Merged
merged 5 commits into from
Apr 30, 2021

Conversation

ArturKovacs
Copy link
Contributor

@ArturKovacs ArturKovacs commented Apr 29, 2021

The activation policy could previously be specified through the window builder. This was incorrect because the activation policy is an application-wide property, not window-specific.

  • Tested on all platforms changed
  • Compilation warnings were addressed
  • cargo fmt has been run on this branch
  • cargo doc builds successfully
  • Added an entry to CHANGELOG.md if knowledge of this change could be valuable to users
  • Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
  • Created or updated an example program if it would help users understand this functionality
  • Updated feature matrix, if new features were added or implemented

@ArturKovacs
Copy link
Contributor Author

@madsmtm please review this.

Copy link
Member

@madsmtm madsmtm left a comment

Choose a reason for hiding this comment

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

Gladly!

Aside: Sorry for the delay on #1759, I will take a look at it some point, just haven't mustered the energy to do it yet - and probably don't have the time to commit myself as a maintainer yet, but again, thanks for the suggestion, I'll let you know if I feel I can take on that responsibility.

src/platform_impl/macos/window.rs Outdated Show resolved Hide resolved
src/platform_impl/macos/app_delegate.rs Show resolved Hide resolved
src/platform_impl/macos/app_delegate.rs Show resolved Hide resolved
src/platform/macos.rs Show resolved Hide resolved
pub struct AuxDelegateState {
/// We store this value in order to be able defer setting the activation policy until
/// after the app has finished launching. If the activation policy is set earlier, the
/// menubar is unresponsive for example.
Copy link
Member

Choose a reason for hiding this comment

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

Add note about Catalina, e.g.:

Suggested change
/// menubar is unresponsive for example.
/// menubar, for example, is initially unresponsive on Catalina and above.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is not true, it's also unresponsive on my 10.11. Is there a version where it's responsive from the start? If there is this could be worded like "the menubar is unresponsive on some systems"

Copy link
Member

Choose a reason for hiding this comment

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

On the current master, that is, after #1903, the menu is responsive on my machine, running MacOS 10.14.6 Mojave - and I thought it was on yours as well? But if I'm mistaken there, then you're right, the menubar is unresponsive on some systems is better.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh. Now I understand what I was confused about. Yes, after #1903 everything works on my system (10.11), but now you enlightened me that that's not the case on 10.15 and 11.

/// Safety: Assumes that Object is an instance of APP_DELEGATE_CLASS
pub unsafe fn get_aux_state_mut(this: &Object) -> RefMut<'_, AuxDelegateState> {
let ptr: *mut c_void = *this.get_ivar(AUX_DELEGATE_STATE_NAME);
// Watch out that this needs to be the correct type
Copy link
Member

Choose a reason for hiding this comment

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

Can't you just set ptr to the correct type above? (If not, there's probably something in Rust's type conversion that I don't understand, bear with me)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The ivar itself is *mut c_void so I guess this better exposes what is happening.

But as far as I know, I could just write let ptr: *mut RefCell<AuxDelegateState> = ... but I'm not a 100% sure and I'm also not sure if the ivar has to be a void pointer instead of a pointer with the actual type.

Copy link
Member

Choose a reason for hiding this comment

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

Fair enough, let's keep it as-is, this we at least know is correct

src/platform_impl/macos/app_state.rs Outdated Show resolved Hide resolved
Copy link
Member

@madsmtm madsmtm left a comment

Choose a reason for hiding this comment

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

Your changes looks fine, now it's just comments 😉

src/platform_impl/macos/app_state.rs Outdated Show resolved Hide resolved
Co-authored-by: Mads Marquart <mads@marquart.dk>
@ArturKovacs ArturKovacs merged commit cdeb1c3 into rust-windowing:master Apr 30, 2021
@ArturKovacs ArturKovacs deleted the act-pol-evlp branch April 30, 2021 09:31
@emilk
Copy link
Contributor

emilk commented Nov 4, 2021

This created a regression: #2051

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants