This repository has been archived by the owner on Feb 25, 2025. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[macOS] Make FlutterEngine support multiple views #37976
[macOS] Make FlutterEngine support multiple views #37976
Changes from all commits
74503c6
e249299
f5335ea
fd7d3d9
d705c82
3ac89d9
0f44c6d
9de9616
ad69a76
c05f0e8
c2ebe66
0625db7
63a41c9
d063600
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know if it's the same as the internal breakage, but this broke
file_selector_macos
, and would potentially break any other Swift plugin as well. In Obj-C the same syntax can be used to call methods and access properties, but that's not the case in Swift, so changing a property to a method is a breaking change, which would make supporting bothmaster
andstable
with a single plugin impossible. We should not change this without a very compelling reason.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is exactly why this PR was reverted. I did this only because I thought it was equivalent (for objC). I'll change it back to proprty syntax.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should there be an empty line between this comment and the previous method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm assuming the reason this is a const global rather than constexpr is that it's part of our public headers and therefore we need it to be pure Obj-C and not Obj-C++?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure which header to put the constexpr to, because the files that rely on this value might not all import the same header. In this way I can put the declaration in any header file and just use it. Also, you can say in this way we're hiding the actual value of this magic value.
Do you think I should try to change it?