Initial keyboard shortcuts configuration implementation #496
78437
app/package-lock.json
generated
@@ -30,6 +30,7 @@
|
||||
"cloudinary-react": "^1.6.7",
|
||||
"get-active-classes": "^0.0.11",
|
||||
"gotrue-js": "^0.9.27",
|
||||
"hotkeys-js": "^3.8.7",
|
||||
"html-to-image": "^1.7.0",
|
||||
"lodash": "^4.17.21",
|
||||
"netlify-identity-widget": "^1.9.1",
|
||||
@@ -40,6 +41,7 @@
|
||||
"react-dropzone": "^11.2.1",
|
||||
"react-ga": "^3.3.0",
|
||||
"react-helmet": "^6.1.0",
|
||||
"react-hotkeys-hook": "^3.4.0",
|
||||
"react-image-crop": "^8.6.6",
|
||||
"react-mosaic-component": "^5.0.0",
|
||||
"react-tabs": "^3.2.2",
|
||||
@@ -56,4 +58,4 @@
|
||||
"postcss-loader": "^6.1.1",
|
||||
"tailwindcss": "^2.2.7"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
|
|
||||
import { Menu } from '@headlessui/react'
|
||||
import { useEffect, useState } from 'react'
|
||||
import { useHotkeys } from 'react-hotkeys-hook';
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
import { useHotkeys } from 'react-hotkeys-hook'
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
import { makeStyles } from '@material-ui/core/styles'
|
||||
import Dialog from '@material-ui/core/Dialog'
|
||||
import { editorMenuConfig } from './menuConfig';
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
import { editorMenuConfig } from './menuConfig'
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
import { useIdeContext } from 'src/helpers/hooks/useIdeContext'
|
||||
|
||||
const SHORTCUT = 'ctrl+/, command+/'
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
const SHORTCUT = 'ctrl+shift+/'
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
|
||||
const useStyles = makeStyles({
|
||||
root: {
|
||||
@@ -15,30 +15,41 @@ const useStyles = makeStyles({
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
Added issue #499 to track this Added issue #499 to track this
|
||||
})
|
||||
|
||||
const AllShortcutsModal = () => {
|
||||
const classes = useStyles()
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
const [open, setOpen] = useState(false)
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
useHotkeys(SHORTCUT, () => setOpen(!open), [open])
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
const classes = useStyles()
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
const [open, setOpen] = useState(false)
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
useHotkeys(SHORTCUT, () => setOpen(!open), [open])
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
|
||||
return (<>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
<Dialog open={open} onClose={() => setOpen(false)} className={classes.root}>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
return (
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
<>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
<Dialog
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
open={open}
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
onClose={() => setOpen(false)}
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Oh yeah lemme check it out, I bet it's a difference between the Modal and the inner content, and maybe I rounded the inner stuff as well and they're basically overlapping. Oh yeah lemme check it out, I bet it's a difference between the Modal and the inner content, and maybe I rounded the inner stuff as well and they're basically overlapping.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
className={classes.root}
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
<div className="bg-ch-gray-700 font-fira-sans max-w-7xl rounded shadow-lg text-ch-gray-300 p-4">
|
||||
<h2 className="text-2xl mb-4">All Shortcuts</h2>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
{ editorMenuConfig.filter(menu => menu.items.length).map(menu =>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
<section key={"allshortcuts-"+menu.name}
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
className="my-6">
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
<h3 className="text-xl border-b-2 pb-2 mb-2">{ menu.label }</h3>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
{ menu.items.map(item => (
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
<div className="flex gap-8 justify-between" key={"allshortcuts-"+menu.name+"-"+item.label}>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
<p>{ item.label }</p>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
<span className="text-right font-fira-code text-ch-gray-400">{ item.shortcutLabel }</span>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
</div>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
<h2 className="text-2xl mb-4">All Shortcuts</h2>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
{editorMenuConfig
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
.filter((menu) => menu.items.length)
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
.map((menu) => (
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
<section key={'allshortcuts-' + menu.name} className="my-6">
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
<h3 className="text-xl border-b-2 pb-2 mb-2">{menu.label}</h3>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
{menu.items.map((item) => (
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
<div
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
className="flex gap-8 justify-between"
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
key={'allshortcuts-' + menu.name + '-' + item.label}
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
<p>{item.label}</p>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
<span className="text-right font-fira-code text-ch-gray-400">
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
{item.shortcutLabel}
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
</span>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
</div>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
))}
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
</section>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
))}
|
||||
</section>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
)}
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
</div>
|
||||
|
Yeah overwriting MaterialUI's default styles is not intuitive Yeah overwriting MaterialUI's default styles is not intuitive
Mmm, we'll move towards headlessui where possible in future. Very tailwind friendly, and friendly to customising styles in general too. Mmm, we'll move towards headlessui where possible in future. Very tailwind friendly, and friendly to customising styles in general too.
|
||||
</Dialog>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
</>)
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
}
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
</Dialog>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
</>
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
)
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
}
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
|
||||
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
export default AllShortcutsModal
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
export default AllShortcutsModal
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
|
||||
|
||||
|
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Should this also have a button in the menu, how will users learn how to get this modal up? Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused. Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor. Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
Ah crap this is all good consideration @Irev-Dev. Here are my recommendations for these 2:
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them? Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
- **All Shortcuts**:`command+/` 👉🏻 `ctrl+shift+?`. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?
- **Reset Layout**: `command+alt+R` 👉🏻 `ctrl+shift+R`. It appears that `ctrl+shift` is a fairly reliable key combination.
Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
One thing that's weird to me is that HotKeys treats One thing that's weird to me is that HotKeys treats `Ctrl` and `Cmd` as the Windows/Mac alternatives, but it's really `Cmd` and `Win` keys that are analogous, usually called the OS key within the browser, and `Ctrl` is a key that both OSes have.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
- ctrl shift ? I think make sense for the modal :)
- test might be good, but not sure if there is a way it pull hotkeys out of monaco without hardcoding them ourselves.
- I think the library does that for practical reasons since ctrl is the most common key used for hotkey for win and cmd is the most common for mac, for example cmd c, cmd v is copy paste.
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really. Want me to open an issue for the tests? I feel like we can do that a bit later, right? Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find [this GH issue comment about it](https://github.com/microsoft/monaco-editor/issues/823#issuecomment-470754000). There doesn't appear to be like `KeybindingsRegistry.getAll()` method or anything like that.
The Monaca online editor is built on top of Monaco and has this hardcoded [list of shortcuts](https://docs.monaca.io/en/products_guide/monaca_ide/editor/) that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And [this issue has been raised](https://github.com/microsoft/monaco-editor/issues/102) in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good. Yeah sure, sounds good.
Yeah sure, sounds good. Yeah sure, sounds good.
Added issue #499 to track this Added issue #499 to track this
Added issue #499 to track this Added issue #499 to track this
|
||||
@@ -1,49 +1,71 @@
|
||||
import { Menu } from '@headlessui/react'
|
||||
import { useHotkeys } from 'react-hotkeys-hook';
|
||||
import { useHotkeys } from 'react-hotkeys-hook'
|
||||
|
||||
export function DropdownItem({ config, state, thunkDispatch }) {
|
||||
useHotkeys(config.shortcut, handleClick)
|
||||
useHotkeys(config.shortcut, handleClick)
|
||||
|
||||
function handleClick(e) {
|
||||
e.preventDefault()
|
||||
config.callback(e, {state, thunkDispatch})
|
||||
}
|
||||
return (
|
||||
<Menu.Item>
|
||||
{({ active }) => (
|
||||
function handleClick(e) {
|
||||
e.preventDefault()
|
||||
config.callback(e, { state, thunkDispatch })
|
||||
}
|
||||
return (
|
||||
<Menu.Item>
|
||||
{({ active }) => (
|
||||
<button
|
||||
className={`${active && 'bg-gray-600'} px-2 py-1 flex justify-between`}
|
||||
className={`${
|
||||
active && 'bg-gray-600'
|
||||
} px-2 py-1 flex justify-between`}
|
||||
onClick={handleClick}
|
||||
>
|
||||
{config.label}
|
||||
{config.shortcutLabel && <span className="text-gray-400 pl-6 text-right">{ config.shortcutLabel }</span> }
|
||||
{config.shortcutLabel && (
|
||||
<span className="text-gray-400 pl-6 text-right">
|
||||
{config.shortcutLabel}
|
||||
</span>
|
||||
)}
|
||||
</button>
|
||||
)}
|
||||
</Menu.Item>
|
||||
)
|
||||
}
|
||||
|
||||
</Menu.Item>
|
||||
)
|
||||
}
|
||||
|
||||
export function Dropdown({
|
||||
label,
|
||||
disabled,
|
||||
children,
|
||||
}: {
|
||||
label: string,
|
||||
disabled: boolean,
|
||||
children: React.ReactNode,
|
||||
}) {
|
||||
return (
|
||||
<div className="relative">
|
||||
<Menu>
|
||||
{({ open }) => (<>
|
||||
<Menu.Button className={"text-gray-100" + (disabled ? " text-gray-400 cursor-not-allowed" : "")} disabled={disabled}>{label}</Menu.Button>
|
||||
{ children &&
|
||||
<Menu.Items static className={(open ? "" : "hidden ") + "absolute flex flex-col mt-4 bg-ch-gray-760 rounded text-gray-100 overflow-hidden whitespace-nowrap border border-ch-gray-700"}>
|
||||
{children}
|
||||
</Menu.Items>
|
||||
}
|
||||
</>)}
|
||||
</Menu>
|
||||
</div>
|
||||
)
|
||||
}
|
||||
label,
|
||||
disabled,
|
||||
children,
|
||||
}: {
|
||||
label: string
|
||||
disabled: boolean
|
||||
children: React.ReactNode
|
||||
}) {
|
||||
return (
|
||||
<div className="relative">
|
||||
<Menu>
|
||||
{({ open }) => (
|
||||
<>
|
||||
<Menu.Button
|
||||
className={
|
||||
'text-gray-100' +
|
||||
(disabled ? ' text-gray-400 cursor-not-allowed' : '')
|
||||
}
|
||||
disabled={disabled}
|
||||
>
|
||||
{label}
|
||||
</Menu.Button>
|
||||
{children && (
|
||||
<Menu.Items
|
||||
static
|
||||
className={
|
||||
(open ? '' : 'hidden ') +
|
||||
'absolute flex flex-col mt-4 bg-ch-gray-760 rounded text-gray-100 overflow-hidden whitespace-nowrap border border-ch-gray-700'
|
||||
}
|
||||
>
|
||||
{children}
|
||||
</Menu.Items>
|
||||
)}
|
||||
</>
|
||||
)}
|
||||
</Menu>
|
||||
</div>
|
||||
)
|
||||
}
|
||||
|
||||
@@ -3,42 +3,49 @@ import Svg from 'src/components/Svg/Svg'
|
||||
import CadPackage from 'src/components/CadPackage/CadPackage'
|
||||
import { editorMenuConfig } from './menuConfig'
|
||||
import AllShortcutsModal from './AllShortcutsModal'
|
||||
import { Dropdown } from './Dropdowns';
|
||||
import { Dropdown } from './Dropdowns'
|
||||
|
||||
const EditorMenu = () => {
|
||||
const { state, thunkDispatch } = useIdeContext()
|
||||
|
||||
return (<>
|
||||
<div className="flex justify-between bg-ch-gray-760 text-gray-100">
|
||||
<div className="flex items-center h-9 w-full cursor-grab">
|
||||
<div className=" text-ch-gray-760 bg-ch-gray-300 cursor-grab px-2 h-full flex items-center">
|
||||
<Svg name="drag-grid" className="w-4 p-px" />
|
||||
|
||||
return (
|
||||
<>
|
||||
<div className="flex justify-between bg-ch-gray-760 text-gray-100">
|
||||
<div className="flex items-center h-9 w-full cursor-grab">
|
||||
<div className=" text-ch-gray-760 bg-ch-gray-300 cursor-grab px-2 h-full flex items-center">
|
||||
<Svg name="drag-grid" className="w-4 p-px" />
|
||||
</div>
|
||||
<div className="grid grid-flow-col-dense gap-6 px-5">
|
||||
{editorMenuConfig.map((menu) => (
|
||||
<Dropdown
|
||||
label={menu.label}
|
||||
disabled={menu.disabled}
|
||||
key={menu.label + '-dropdown'}
|
||||
>
|
||||
{menu.items.map((itemConfig) => (
|
||||
<itemConfig.component
|
||||
state={state}
|
||||
thunkDispatch={thunkDispatch}
|
||||
config={itemConfig}
|
||||
key={menu.label + '-' + itemConfig.label}
|
||||
/>
|
||||
))}
|
||||
</Dropdown>
|
||||
))}
|
||||
</div>
|
||||
<button
|
||||
className="text-ch-gray-300 h-full cursor-not-allowed"
|
||||
aria-label="editor settings"
|
||||
disabled
|
||||
>
|
||||
<Svg name="gear" className="w-6 p-px" />
|
||||
</button>
|
||||
</div>
|
||||
<div className="grid grid-flow-col-dense gap-6 px-5">
|
||||
{ editorMenuConfig.map(menu => (
|
||||
<Dropdown label={menu.label} disabled={menu.disabled} key={menu.label +"-dropdown"}>
|
||||
{ menu.items.map(itemConfig =>
|
||||
<itemConfig.component
|
||||
state={state}
|
||||
thunkDispatch={thunkDispatch}
|
||||
config={itemConfig}
|
||||
key={menu.label +"-"+ itemConfig.label } />
|
||||
) }
|
||||
</Dropdown>
|
||||
)) }
|
||||
</div>
|
||||
<button
|
||||
className="text-ch-gray-300 h-full cursor-not-allowed"
|
||||
aria-label="editor settings"
|
||||
disabled
|
||||
>
|
||||
<Svg name="gear" className="w-6 p-px" />
|
||||
</button>
|
||||
<CadPackage cadPackage={state.ideType} className="px-3" />
|
||||
</div>
|
||||
<CadPackage cadPackage={state.ideType} className="px-3" />
|
||||
</div>
|
||||
<AllShortcutsModal/>
|
||||
</>)
|
||||
<AllShortcutsModal />
|
||||
</>
|
||||
)
|
||||
}
|
||||
|
||||
export default EditorMenu
|
||||
export default EditorMenu
|
||||
|
||||
@@ -5,98 +5,104 @@ import { useSaveCode } from 'src/components/IdeWrapper/useSaveCode'
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
Yup it yelled at me now! Yup it yelled at me now!
|
||||
import { DropdownItem } from './Dropdowns'
|
||||
|
||||
export function cmdOrCtrl() {
|
||||
return /(Mac|iPhone|iPod|iPad)/i.test(navigator.platform) ? '⌘' : 'Ctrl'
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
return /(Mac|iPhone|iPod|iPad)/i.test(navigator.platform) ? '⌘' : 'Ctrl'
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
}
|
||||
|
||||
const fileMenuConfig = {
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
name: 'file',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
label: 'File',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
disabled: false,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
items: [
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
{
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
label: 'Save & Render',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
shortcut: 'ctrl+s, command+s',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
shortcutLabel: cmdOrCtrl() + ' S',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
component: (props) => {
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
const { state, config } = props
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
const handleRender = useRender()
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
const saveCode = useSaveCode()
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
function onRender(e) {
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
e.preventDefault()
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
handleRender()
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
saveCode({ code: state.code })
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
}
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
config.callback = onRender
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
return <DropdownItem {...props} />
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
},
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
},
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
{
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
label: 'Download STL',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
shortcut: 'ctrl+shift+d, command+shift+d',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
shortcutLabel: cmdOrCtrl() + ' Shift D',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
component: (props) => {
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
const { state, thunkDispatch, config } = props
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
const handleStlDownload = makeStlDownloadHandler({
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
type: state.objectData?.type,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
ideType: state.ideType,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
geometry: state.objectData?.data,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
quality: state.objectData?.quality,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
fileName: PullTitleFromFirstLine(state.code || ''),
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
thunkDispatch,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
})
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
config.callback = handleStlDownload
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
return <DropdownItem {...props} />
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
}
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
const fileMenuConfig: EditorMenuConfig = {
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
name: 'file',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
label: 'File',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
disabled: false,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
items: [
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
{
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
label: 'Save & Render',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
shortcut: 'ctrl+s, command+s',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
shortcutLabel: cmdOrCtrl() + ' S',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
component: (props) => {
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
const { state, config } = props
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
const handleRender = useRender()
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
const saveCode = useSaveCode()
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
function onRender(e) {
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
e.preventDefault()
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
handleRender()
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
saveCode({ code: state.code })
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
}
|
||||
]
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
config.callback = onRender
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
return <DropdownItem {...props} />
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
},
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
},
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
{
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
label: 'Download STL',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
shortcut: 'ctrl+shift+d, command+shift+d',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
shortcutLabel: cmdOrCtrl() + ' Shift D',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
component: (props) => {
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
const { state, thunkDispatch, config } = props
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
const handleStlDownload = makeStlDownloadHandler({
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
type: state.objectData?.type,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
ideType: state.ideType,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
geometry: state.objectData?.data,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
quality: state.objectData?.quality,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
fileName: PullTitleFromFirstLine(state.code || ''),
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
thunkDispatch,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
})
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
config.callback = handleStlDownload
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
return <DropdownItem {...props} />
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
},
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
},
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
],
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
}
|
||||
|
||||
const editMenuConfig = {
|
||||
name: 'edit',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
label: 'Edit',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
disabled: true,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
items: [],
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
name: 'edit',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
label: 'Edit',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
disabled: true,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
items: [],
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
}
|
||||
|
||||
const viewMenuConfig = {
|
||||
name: 'view',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
label: 'View',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
disabled: false,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
items: [
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
{
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
label: 'Reset layout',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
shortcut: 'ctrl+alt+r, command+alt+r',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
shortcutLabel: cmdOrCtrl() + ' Alt R',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
component: (props) => {
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
const { config, thunkDispatch } = props
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
config.callback = () => thunkDispatch({ type: 'resetLayout' })
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
return <DropdownItem {...props } />
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
}
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
},
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
],
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
name: 'view',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
label: 'View',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
disabled: false,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
items: [
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
{
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
label: 'Reset layout',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
shortcut: 'ctrl+shift+r',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
shortcutLabel: 'Ctrl Shift R',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
component: (props) => {
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
const { config, thunkDispatch } = props
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
config.callback = () => thunkDispatch({ type: 'resetLayout' })
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
return <DropdownItem {...props} />
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
},
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
},
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
{
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
label: 'All shortcuts',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
shortcut: 'ctrl+shift+/',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
shortcutLabel: 'Ctrl Shift /',
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
component: (props) => {
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
const { config } = props
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
const [open, setOpen] = useShortcutModalContext()
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
config.callback = () => setOpen(true)
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
return <DropdownItem {...props} />
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
},
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
},
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
],
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
}
|
||||
|
||||
export const editorMenuConfig = [
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
fileMenuConfig,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
editMenuConfig,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
viewMenuConfig,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
]
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
export const editorMenuConfig = [fileMenuConfig, editMenuConfig, viewMenuConfig]
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
|
||||
// TODO: set up these types properly. The callback is especially giving me trouble.
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
export interface EditorMenuItemConfig {
|
||||
label: string,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
shortcut: string,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
shortcutLabel: React.ReactNode | string,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
callback: any, // I don't understand how to make this a more specific type
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
label: string
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
shortcut: string
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
shortcutLabel: React.ReactElement | string
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
component: (props: any) => React.ReactElement
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
}
|
||||
|
||||
export interface EditorMenuConfig {
|
||||
name: string,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
label: string,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
disabled: boolean,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
items: Array<EditorMenuItemConfig>,
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
}
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
name: string
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
label: string
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
disabled: boolean
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
items: Array<EditorMenuItemConfig>
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
}
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
|
||||
|
||||
|
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
if you make this: Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since if you make this:
```suggestion
const fileMenuConfig: EditorMenuConfig = {
```
Thdn the linter (assuming you've got ts setup with your editor) should tell you if your obeying your own types for this menu, and I think you're not since `component` doesn't exist on `EditorMenuItemConfig`.
I think callback is not needed now and component is? I think callback is not needed now and component is?
I think callback is not needed now and component is? I think callback is not needed now and component is?
Yup it yelled at me now! Yup it yelled at me now!
Yup it yelled at me now! Yup it yelled at me now!
|
||||

Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Should this also have a button in the menu, how will users learn how to get this modal up?
Why did you choose this combo, is this a pattern elsewhere? I'm concerned that is the same hotkey as commenting a line in the editor, since the editor is currently swallowing this hotkey so it still works in the editor but seems weird having two different behaviour depending on where you're focused.
Maybe it's a mac only thing, but similar to the above cmd alt R only resets the viewer when I'm not focused on the edit, because its already a hotkey in the editor. Seems like we're going to be competing for hotkeys from the monaco editor.
Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
command+/👉🏻ctrl+shift+?. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?command+alt+R👉🏻ctrl+shift+R. It appears thatctrl+shiftis a fairly reliable key combination.Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
Ah crap this is all good consideration @Irev-Dev.
Here are my recommendations for these 2:
command+/👉🏻ctrl+shift+?. This is what Figma's shortcut to show shortcuts is. I agree this should have a button in the menu. Would it go under View?command+alt+R👉🏻ctrl+shift+R. It appears thatctrl+shiftis a fairly reliable key combination.Separately, should we have a part of this component or its tests have a list of the Monaco shortcuts to verify any new ones aren't stepping on them?
One thing that's weird to me is that HotKeys treats
CtrlandCmdas the Windows/Mac alternatives, but it's reallyCmdandWinkeys that are analogous, usually called the OS key within the browser, andCtrlis a key that both OSes have.One thing that's weird to me is that HotKeys treats
CtrlandCmdas the Windows/Mac alternatives, but it's reallyCmdandWinkeys that are analogous, usually called the OS key within the browser, andCtrlis a key that both OSes have.Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like
KeybindingsRegistry.getAll()method or anything like that.The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah doesn't appear to be a great way to pull them out programmatically, only was able to find this GH issue comment about it. There doesn't appear to be like
KeybindingsRegistry.getAll()method or anything like that.The Monaca online editor is built on top of Monaco and has this hardcoded list of shortcuts that we could pull from for a hardcoded solution. I think they'll be pretty stable so that might not be too bad? And this issue has been raised in Monaco for an easy API for swapping out keyboard shortcuts, I couldn't find a clean holistic API for keybindings at all really.
Want me to open an issue for the tests? I feel like we can do that a bit later, right?
Yeah sure, sounds good.
Yeah sure, sounds good.
Added issue #499 to track this
Added issue #499 to track this