Windows application menu take two #991
Conversation
We're not using it for anything
To accomodate for icon and menu bar
Only when some menu is open
This allows us to capture arrow keys even though no menu items have focus
Checking whether we're collapsed or not should be enough
The menu is closed in onWindowKeyDown
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
|
|
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
Member
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.
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
Member
This one is also relevant to your test setup, in case you're in a VM.
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
Member
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...
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...
niik
Mar 28, 2017
Author
Member
Good call
Good call
| private renderTitlebar() { | ||
| const winControls = __WIN32__ | ||
| ? <WindowControls /> | ||
| : null | ||
|
|
||
| // On windows it's not possible to resize a frameless window if the |
shiftkey
Mar 28, 2017
Member
capital W for Windows
capital W for Windows
| private onKeyDown = (event: React.KeyboardEvent<HTMLDivElement>) => { | ||
|
|
||
| if (event.key === 'Escape') { | ||
| // Are we currently collapsed? |
shiftkey
Mar 28, 2017
Member
Duplicate comments and checks make me think this check could be extracted a variable or function to make this easier to understand. Thoughts?
Duplicate comments and checks make me think this check could be extracted a variable or function to make this easier to understand. Thoughts?
|
|
|
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
Member
We seem to have dropped the openMenu && openMenu.id === item.id check here as part of the refactoring. No longer necessary?
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
Author
Member
Nope, this is ensured at the parent component already, it was a remnant from a colder darker era
Nope, this is ensured at the parent component already, it was a remnant from a colder darker era
shiftkey
Mar 28, 2017
Member
Then onward and upward!
Then onward and upward!
|
The support of cross=platform titlebar from Electron is nasty, maybe you guys should consider to PR your efforts to the Electron repo and makes it kinda a standard. |
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