-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Partial move to SwiftUI lifecycle #1152
Conversation
Signed-off-by: Wouter01 <wouterhennen@gmail.com>
Signed-off-by: Wouter01 <wouterhennen@gmail.com>
Signed-off-by: Wouter01 <wouterhennen@gmail.com>
Signed-off-by: Wouter01 <wouterhennen@gmail.com>
Signed-off-by: Wouter01 <wouterhennen@gmail.com>
Signed-off-by: Wouter01 <wouterhennen@gmail.com>
Signed-off-by: Wouter01 <wouterhennen@gmail.com>
Signed-off-by: Wouter01 <wouterhennen@gmail.com>
Signed-off-by: Wouter01 <wouterhennen@gmail.com>
Signed-off-by: Wouter01 <wouterhennen@gmail.com>
Signed-off-by: Wouter01 <wouterhennen@gmail.com>
Signed-off-by: Wouter01 <wouterhennen@gmail.com>
Signed-off-by: Wouter01 <wouterhennen@gmail.com>
Signed-off-by: Wouter01 <wouterhennen@gmail.com>
Signed-off-by: Wouter01 <wouterhennen@gmail.com>
Signed-off-by: Wouter01 <wouterhennen@gmail.com>
Signed-off-by: Wouter01 <wouterhennen@gmail.com>
The proposed menu API doesn't quite make sense to me. // Hide this button when option is pressed
Button("Some menu item to be replaced when pressing option") {
}
.keyboardShortcut("c", modifiers: [.command])
.hideOnModifierKeys([.option])
// Show this button when option is pressed
Button("Some hidden menu item visible when pressing option") {
}
.keyboardShortcut("c", modifiers: [.command, .option])
.showOnModifierKeys([.option]) Wouldn't this be more appropriate rather than combining it with the keyboardShortcut modifier? |
Yeah, definately. But I'm limited to what I can do here. I somehow need to know in a method in AppKit that a SwiftUI menu item wants to be a hidden menu item.
These are the only two options available atm as far as I know, as these are the only two properties that are customizable with SwiftUI. So, I went with the latter. The I went this way as
|
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.
The changes look good overall, just have some questions about the settings pane and the CommandsForEach
struct.
Signed-off-by: Wouter01 <wouterhennen@gmail.com>
5d115a9
Signed-off-by: Wouter01 <wouterhennen@gmail.com>
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.
Looks great now, just one more tiny thing for some future-proofing.
Signed-off-by: Wouter01 <wouterhennen@gmail.com>
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.
LGTM
Description
This PR moves parts of CodeEdit to the SwiftUI lifecycle. This way, the settings window can take full advantage of the new APIs released with macOS Ventura. Other views, like the Welcome Window, have also been ported and simplified. Methods are provided so there's compatibility with AppKit.
This PR also fixes some small issues, such as Cmd+W not working properly for closing windows. (This should actually close tabs, but we'll keep it windows for now).
No changes should be visible, except the menu bar which might look slightly different.
The old settings menu option has been moved over to
Old Settings...
, which has the shortcut Command + Option + ','A nice bonus is a new API to easily add hidden options to a SwiftUI
contextMenu
. This was needed for some menus of the menubar, but it also works in all other contextMenus throughout the app.Example:
Related Issues
#1066
Checklist
@FirstResponder
Property WrapperForEach
inCommands
.Modify the menu bar so it's somewhat equal to the previous implementation:
Additional