keyboardio/chrysalis

Graphical configurator for Kaleidoscope-powered keyboards

chrysalis's Issues

Turn the DevTools button into a floating action button

Instead of - or perhaps in addition to - hiding the DevTools toggle on the settings page, make it a floating action button, present on all pages instead. This would allow one to pop it up anytime, without having to navigate away.

(Having a key binding for it would also be a good idea...)

Automated release building

In order to not make the release process a major pain, we need to set up automated building for all three major platforms.

Current state:

• Linux x64, AppImage (built natively on Linux)
• Windows x64, setup.exe (built natively on Win10)
• OSX dmg

We still need to figure out where to publish artifacts to. We need to publish builds for releases only, and publish after the release. We should also only build on a tag event.

Issues on OSX

There are a number of issues we have identified on OSX, collected here in bulk.

• Sometimes connecting to the keyboard times out.
• Pulling the keymap works, but updating does not.

Show layers as tabs

PROGMEM layers are editable

PROGMEM layers can be edited and saved, or course with no actual results.

Custom names layers

The firmware does not save custom names given to macros, tap-dance, or leader keys, nor layer names. Yet, those are all interesting and useful information. Since we want to support saving a layout, and importing them too, we could also allow the user to name the layers, and give custom names to any of the keys on the board. Custom names would be displayed on the keymap instead of the normal label.

One restriction I'd add, is that this would only affect the primaryLabel; extraLabel would still come from DisplayTransformer. At least, for keys. For layers, there should be no such restrictions.

Use a list instead of a dropdown for keycode selection

Move the "Save Changes" button to where the probe/close ones are

Split the palette into two columns

There's plenty of room beside the keyboard graphics, split the palette into two columns so we eat less vertical space.

What should happen when right clicking a key?

It would be useful if we did something when right clicking a key on the keymap. Left clicking selects it, but what about right click?

• It could open a context menu, with options that depend on the type of the key. For example, layer keys could have a jump to layer #n option.
• It could do an action that depend on the type of key, like, jump to a layer.

The former is less surprising, the second requires less clicking for the - likely - most common operation.

Figure out the UX of read-only (PROGMEM) layers

After uploading new firmware, re-detect capabilities too

After successfully flashing firmware, we should re-detect the keyboard capabilities.

The palette should be to the right of the keyboard

There's plenty of space (at least when running full screen) to the right of the keyboard on the colormap editor page. Move the palette there, and make it vertical.

Consider removing the steps from the layout editor loader

The steps were originally added to provide better feedback during a reasonably slow operation. With recent changes, this operation is no longer slow, and the extra info isn't visible long enough to be useful. As such, I think it can be safely removed.

Provided that we still work, and that we're equally fast on OSX...

Improve the speed dial behaviour

When mousing over it, it should open, and close on mouse leave. If clicked, it should remain open. Clicking again should close it, even if the mouse is still over it.

We need an exit button

Right now the only way to exit the application is to close it. We should provide an exit button, both on the dashboard, and on the keyboard selection screen too.

Reduce the amount of snackbars

The layout and colormap editors pop up way too many snackbars. It's great to see progress, but... the snackbars are obstructing the save button and when things work normally, they're annoying as hell.

Fix-sized keyboard images

On one hand, it's great when keyboard images are responsive. On another hand, it's annoying when they jump around rapidly when resizing the window. We should have set sizes for a few window sizes: 1920, 1600, 1024. 1024 is our minimum width, so no need to go below that.

Media queries should help.

Add a "report issue" button somewhere

We should have a "report issue" button somewhere. On the dashboard, and on the keyboard selector too.

Display selected shifted keycodes as their shifted variant

We currently display all LSHIFT(x) keys with Shift as extraLabel, and the key that will have shift applied as label. For some keys (such as numbers and punctuation) displaying the shifted symbol instead would make more sense.

Note, this should only apply to selected keys, and only when Shift is the only modifier.

No need for keys to be selectable in the colormap editor

Unlike the layout editor, the colormap editor does not benefit from keys being selectable. It is actively harmful, when one wants to play with colors, and a single (nearby) key: it keeps deselecting.

Since selection doesn't do anything, remove that feature.

Support augmenting normal keys with modifiers

Some of the UI is already laid out (but disabled) for augmenting keys with modifiers. We need to finish up the feature.

Check features on connect

When connecting to the keyboard, check if colormap and keymap return something sensible (non-empty), and only display the respective entries in the drawer if they're present. We should re-check every time the keyboard connects, so after flashing too.

Add a way to flash compiled firmware

Probably best done via avrgirl. The old Chrysalis had a way to do that, so shall we.

The key selector is unusable at 1024x768

Error handling does not exist

If the keyboard does not have Focus, or if it isn't connected, or if it gets disconnected - we don't handle that at all. Unless one has the console open, they wouldn't even know.

This needs to be addressed. The handling doesn't have to be pretty (alert, or an error screen works), but there should be hints.

Handle disconnects more gracefully

When pulling the keyboard out, we get an uncaught error, and an eventual timeout. We should handle the flush error ourselves.

Don't show the inspector by default

Even in development builds, where dev tools are enabled, the inspector should not show up by default, because that makes it harder for end-users to use Chrysalis, and also sends the wrong message: "this isn't for me yet".

We should start up with the inspector closed, and provide a way to open it instead. The settings menu sounds like a good place for this toggle.

lift out the keymap transformer

The current keymap transformer is not tied to the bundle, and might be useful elsewhere too. It should be lifted out into its own library.

Make it possible to scan USB devices

Perhaps make it automatic too, on the keyboard selector screen.

Support DualUse keys

Should work at lower resolutions too

Right now, we pretty much require an 1920x1080 resolution to avoid scroll bars. We shouldn't. We should display something useful at 1024x768 and up, preferably without scroll bars. Or if there has to be one, let it be the vertical one.

Persist data between pages

Right now, state is local to the pages. When one switches from the info page to the layout editor, it will query the keyboard. Switching back to info, then back to layout editor again, and the query will be performed again. This is slow, and inefficient. Since we're locking the serial port for ourselves, it is safe to persist this data somewhere globally.

We do need to provide a way to purge this cached info. We won't pre-load all of it either, the initial load will still happen on the first page visit. But the next visit should not do another query.

Support working with unknown keycodes

We should not be limited to just the known set of keycodes. Any keycode Chrysalis does not recognise, should still be editable: just an input field that accepts a number.

Add a way to select the default layer

Appbar should fill the whole width

The AppBar on the keymap and colormap editors should fill the whole width of the content area, and have no padding on top either. The rest of the content shall remain padded, however.

When not finding Focus, offer a recent factory firmware

When not finding Focus, the info page should offer a recent factory firmware for uploading. Possibly in a separate box, so we don't have to butcher the file selector to support this special case.

Bouncing "save changes" button

The "Save changes" button is under the keymap editor AND the selector. Thus, when the selector increases in height, the save changes button jumps around, even though the keyboard layout did not move.

We should move the button to a place where it doesn't bounce.

Handle early errors in production

When running in production mode, the DevTools are not available. Even in Development mode, DevTools are closed by default. So any error that happens before the initial render, is not available. If such an error happens, we end up with a very unhelpful empty white screen.

We should catch these, and produce an error page, perhaps with DevTools open. For this, we need to ship production builds with devtools installed (and considering we're not even alpha, I believe this is fine; we'll remove it once we're past beta).

"Scan devices" is sometimes erroneously greyed out

The "Scan devices" button on the keyboard selector page is sometimes greyed out erroneously. We should not disable it while the keyboard scan is running, or we should re-enable it once it's done and didn't find any boards.

Because right now, we can end up in a situation where the attach detection doesn't work, and we can't press the button because it's greyed out.

Support for changing Macro keys

The key selector currently displays macro keys as a dial, and things aren't quite wired up correctly yet (read: it doesn't work). It might make sense to display it as a grid of 32 numbers, until we figure out something better.

Flashing a new firmware results in white screen

I noticed this while testing the 0.0.6 release: when flashing a new firmware, when it goes into bootloader mode, we end up with a white screen. I think it's the detach detection kicking in - which should be disabled during flashing.

Support more hardware

It would be nice if Chrysalis supported more hardware out of the box.

Add a way to explicitly rescan USB devices

While we have some code that listens for USB attach/detach events, that code doesn't appear to work on Windows. We should add an explicit rescan button somewhere to the keyboard selector page.

Figure out a better way to present the features in the SpeedDial FAB

Thanks to @davidaue for digging up the Material Design recommendation, namely: "Only use a FAB if it is the most suitable way to present a screen’s primary action."

The stuff in the speed dial does not meet that requirement. As such, we should figure out a better way to present those things. Perhaps an action bar at the bottom? A thin one? That could still go on every page globally.

improved filtering & display

Instead of having the "top" label included in the select, split stuff into smaller categories, so we can remove the top label, and have the much more descriptive category instead.

Lift out chrysalis-colormap

src/renderer/focus/chrysalis-colormap.js should be lifted out into its own plugin. It was always intended to be outside of this bundle, but for the sake of convenience, it was developed within.

One Big List to rule them all

We currently use a keycode->label transform function to turn keycodes into something more presentable. This has a few drawbacks, the main one being that we can't easily reuse the rules for presenting a structured set of key possibilities, stuff the user can choose from.

Since there are only 64k possible keycodes, we might as well have one big, well annotated table instead.

(Thanks @obra for pushing this idea)

Output keymaps as code for pasting into an ino

It would be nice if there was a way to get the code representation of the current keymaps for pasting into an ino. Even just putting it on the clipboard would work fine. Being able to name the layers would be a good compliment to this so the layer enum could be maintained.

Not finding Focus should not be an error

We have a firmware flashing page, which does not require Focus. If we can't find Focus on the device, we should let the user know on the landing screen after connecting, but still allow them to flash new firmware.