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.

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.

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.

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.

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.

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.

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.

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

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.

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

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.

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).

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

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.

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.

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.

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

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)

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

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.

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...)

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...

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.

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

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

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.