-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keyboard Configurator Design Updates #146
Comments
A couple things I hadn't considered earlier:
How should this look for internal keyboards? #141 adds "Non-US \" for built in keyboards. With this design, and without adding any more keycodes for builtin keyboards, this would leave exactly one key in "Extras", which would be undesirable. |
Could we add other extras to the built-in keyboards? |
I believe built-in keyboards use PS/2 scan code set 2: https://wiki.osdev.org/PS/2_Keyboard#Scan_Code_Set_2. Things like F13 don't seem to exist, and I don't think mouse actions would be possible. |
So nothing that is on Extras for Launch would be possible for the built-in keyboards, right? Neither would be Tap-Hold or Macros. |
Nothing other than "Non-US \", it seems. |
Initial implementation of #146. Backend representation for mod-tap, layer-tap, and modifiers+basic keycode, with conversion to and from text format and numeric keycode. Add shift-select for modifiers with a non-modifier key, extras tab, and tap-hold section. Sensitivity needs to be set based on whether shift is held and what is already selected. Getting this to work properly is awkward with how GTK modifiers are handled. More things need to be added to extras, the layout for basic keys needs to be updated for the latest design, and various style details need to be addressed. And it needs to not show these things for internal keycodes.
This mockup doesn't seem to include the arrow keys in the picker? |
Ah, those are still in navigation, as they were previously. Perhaps laying those out more like they are on the keyboard could make them easier to find. |
Initial implementation of #146. Backend representation for mod-tap, layer-tap, and modifiers+basic keycode, with conversion to and from text format and numeric keycode. Add shift-select for modifiers with a non-modifier key, extras tab, and tap-hold section. Sensitivity needs to be set based on whether shift is held and what is already selected. Getting this to work properly is awkward with how GTK modifiers are handled. More things need to be added to extras, the layout for basic keys needs to be updated for the latest design, and various style details need to be addressed. And it needs to not show these things for internal keycodes.
Initial implementation of #146. Backend representation for mod-tap, layer-tap, and modifiers+basic keycode, with conversion to and from text format and numeric keycode. Add shift-select for modifiers with a non-modifier key, extras tab, and tap-hold section. Sensitivity needs to be set based on whether shift is held and what is already selected. Getting this to work properly is awkward with how GTK modifiers are handled. More things need to be added to extras, the layout for basic keys needs to be updated for the latest design, and various style details need to be addressed. And it needs to not show these things for internal keycodes.
The keypad in the mockup has |
Is there a branch available with the current progress of this redesign? |
I think |
This looks great ! I'm glad this is being worked on. |
In my opinion, these updates are really badly needed. I just opened up my Launch Heavy today, excited to customize it, and I was really disappointed by the lack of options. On the ancient gaming keyboard I've been using, I could set it so when I hit Control, it lit only the keys for shortcuts I use (e.g. C, and V), set shortcuts (like Ctrl+Fn+1 to switch to a different layer), et cetera. I checked out the |
I was able to get the branch to work with my new launch_heavy_3 by applying the changes from 09d7081, plus replacing the contents of |
I'd like to echo this sentiment. I bought my Launch over a year ago and have been watching this issue eagerly ever since. The last change to |
I have no timeline predictions regarding when we can put more time into this. Most of our attention is on COSMIC DE currently. If you want more advanced functionality than what the configurator currently provides, I'd recommend manual QMK firmware customization and flashing. |
Changing Grouping of Keys
We're using tabs to help us organize the new keys and QMK features we want to support. Most of our current keys will go into "Basics," many of the extras will go into "Extras," and the new features for Tap-Hold and Macros will each have their own tab.
On the "Basics" tab:
On the "Extras" tab:
Updating Keycap Styling in Tabs
Within the keycap selection area underneath the tabs, should have a light gray fill (#e9e9e9) with a 1px inside border (#c8c8c8). There will be a 4px padding inside the keycap borders to ensure that the text never gets too close to the sides.
In the event that the text is too large for the keycap (as can happen in the top keymap), the text will be truncated with a "..." and the full text of the key can be viewed by looking at the selected key in the key selection area.
Support for Combined Modifiers
In our previous configurator, keys could only have a single modifier or key assigned. QMK also supports the ability to chain modifier keycodes. For example, one key can do both Left Shift and Left Control. Optionally, you can add another keypress along with modifiers (e.g. Left Control + Left Shift + Up).
In our new configurator, users will be able to select multiple modifiers (plus an additional keycode) by using Shift and clicking on the desired keys. This will give users the ability to replicate the function of "Hyper" and "Meh" keys for keyboards that support it.
Keys that aren't supported within chained modifiers, such as advanced keycodes or modifiers from opposite sides, will be disabled in the key selection groups when Shift is pressed after having already selected the first desired key.
Support for Mod-Tap and Layer-Tap
QMK supports keys that have different actions on hold and on tap. We're calling that feature "Tap-Hold" and giving it another tab below the Launch key map.
Users must select a hold action, and then a tap action. For the hold action, users can either select modifiers or access layer keys (the latter acting as QMK's "Layer Tap").
The selected key in the Launch keymap will show a split-key design with both a tap and hold action. When a hold has been selected, but a tap has not yet been selected, a lighter gray placeholder will appear saying "tap" on the bottom of the key.
The tap-hold modifiers are one example of how incompatible modifiers are disabled when Shift is depressed.
Prototype
Some features describe above can be seen in an online prototype: Link.
This prototype shows the groupings and tabs for "Basics," "Extras," and "Tap-Hold." Through the prototype you can set the spacebar to a Tap-Hold key with the actions of "Left Shift" on hold and "Enter" on tap.
The text was updated successfully, but these errors were encountered: