Windows application menu take two #991
Conversation
niik
added
some commits
Feb 28, 2017
niik
added
some commits
Mar 14, 2017
niik
referenced
this pull request
Mar 16, 2017
Closed
App crashes when clicking on any item in the Edit menu on Windows #1040
niik
added
some commits
Mar 16, 2017
niik
added
some commits
Mar 22, 2017
niik
changed the title from
[WIP] Windows application menu take two to Windows application menu take two
Mar 22, 2017
|
I believe this is finally ready for a first review! |
|
Looking good so far. One question I have is around how the access keys are displayed. What I was hoping to see was something like in Fiddler. Here's a GIF of me pressing ALT a couple of times with the window focused:
EDIT: having the It looks like this current version needs me to interact with the menu with my mouse while holding ALT to get these to show. The other way seems to be to press a known chord - e.g.
Is this something on your radar? |
shiftkey
reviewed
Mar 24, 2017
View changes
This feels pretty great, and I'm happy to polish this further based on @niik's feels about addressing the access key visibility, rather than drag this out.
| + | ||
| + const delta = direction === 'next' ? 1 : -1 | ||
| + | ||
| + // http://javascript.about.com/od/problemsolving/a/modulobug.htm |
shiftkey
self-assigned this
Mar 24, 2017
niik
added
some commits
Mar 24, 2017
Good catch, we should indeed support that scenario. I modeled the interactions after how Notepad does things as that seemed like a good example of how things should be done. I've documented some of my findings in https://github.com/desktop/desktop/blob/88e4525ac9f8f94392eff44ca35f8e891557ed8b/docs/windows-menu-bar.md I'm pretty happy with the current state so it's time for another look
|
shiftkey
requested changes
Mar 28, 2017
View changes
Shout out to some great docs. I'm mostly nit-picking things now.
I'd also love @joshaber or @iAmWillShepherd to pull this down and test it out a bit, just incase I've missed something.
| + | ||
| +## Keyboard navigation | ||
| + | ||
| +When a user is holding down the `ALT` key the access-keys (which is separate from |
shiftkey
Mar 28, 2017
Contributor
Reviewer's note: if you're using something like Parallels here you might see the Option/ALT key behave differently during testing this - it'll raise the keydown and keyup events after you release the key on the host OS.
If you bust out your Onscreen Keyboard in the guest OS you'll see the right timing for events be sent to the app.
| +File -> New Branch item a user should be able to press `ALT+F` followed by `B`. | ||
| + | ||
| +Pressing the `ALT` key and releasing it without pressing an access key should | ||
| +put focus on the first top level menu item if no menu is currently expanded. If |
shiftkey
Mar 28, 2017
Contributor
This one is also relevant to your test setup, in case you're in a VM.
| + * Whether or not to render the accelerator (shortcut) next to the label. | ||
| + * This can be turned off when the menu item is used as a stand-alone item | ||
| + */ | ||
| + readonly renderAcceleratorText?: boolean |
shiftkey
Mar 28, 2017
Contributor
Is it worth calling out the default behaviour here when no value is defined? Both this and renderSubMenuArrow seem to default to rendering when no value set, which might be confusing to the caller...
| private renderTitlebar() { | ||
| const winControls = __WIN32__ | ||
| ? <WindowControls /> | ||
| : null | ||
| + // On windows it's not possible to resize a frameless window if the |
| + private onKeyDown = (event: React.KeyboardEvent<HTMLDivElement>) => { | ||
| + | ||
| + if (event.key === 'Escape') { | ||
| + // Are we currently collapsed? |
shiftkey
Mar 28, 2017
Contributor
Duplicate comments and checks make me think this check could be extracted a variable or function to make this easier to understand. Thoughts?
niik
added
some commits
Mar 28, 2017
|
|
|
Damn, this is a hell of a thing. Works well in the cursory testing I did |
| - ? 'open' | ||
| - : 'closed' | ||
| - | ||
| + const dropDownState = this.isMenuOpen ? 'open' : 'closed' |
shiftkey
Mar 28, 2017
Contributor
We seem to have dropped the openMenu && openMenu.id === item.id check here as part of the refactoring. No longer necessary?
niik
Mar 28, 2017
Contributor
Nope, this is ensured at the parent component already, it was a remnant from a colder darker era
niik commentedMar 1, 2017
•
edited
This implements a custom menu bar component on Windows, see #836 for more details on why.
Navigating with mouse
Navigating with keyboard
This shows me hitting
Alt+Fto open the file menu and thenOto open Options.Things this does not do / known limitations
Full screen
The menu bar is currently not accessible when running the app in full-screen. I plan to tackle that in a separate PR rather than drag this out any longer.
Submenus
Sub menus are not handled with any grace at the moment. They work but they do not position themselves as one would expect. We currently don't have any sub menus for top level menus so I don't plan to tackle that until it becomes a problem as it is non-trivial to implement well.
Fixes #836