Chrysalis
Chrysalis copied to clipboard
keyboardio
Editor: Add a toolbox above the keyboard, for various editing tools
The ToolBox is intended to hold a small selection of tools to aid working with the keymap, such as an eraser (the only one currently implemented). To make these tools easily accessible, they're placed above the keyboard, rather than at the sidebar.
https://user-images.githubusercontent.com/17243/193250475-67251b05-25e9-4bfe-94e6-103f22445e61.mp4
Still trying to find a proper icon. I'd love to show an eraser, but Material Icons do not have an icon like that. Other tools we could add to the toolbox include: full layer clear, layer copy, layer paste. Might be able to move the "Backup & Restore" stuff here, too, in some form.
For now, only an Eraser is implemented, and it's still a work in progress, but opening a draft to seek feedback about the idea.
Rather than sticking it above the keyboard, let's expand the panel containing the 104 key keyboard to contain the toolbox.
Where I'm coming from specifically is that this adds a new, third area you might click in to change the value of a key (in addition to the sidebar and the floating keymap. it gets...kind of incoherent very quickly.
nod
I see that. I'm not happy with it being on the top either - we used to have such a toolbar way back when, and got rid of it for similar reasons. I'm just not very happy about putting more stuff on the floating key picker, either. But I have no better idea, so will give the picker ago, it will likely turn out to be superior, even if not perfect.
I just tried to put this onto the floating key picker, and I hate it. :(
Reason being, when any tool other than the default is in use, I'd love to hide the key picker, because its in the way. Having the key picker visible even when we're using an Eraser or Fill tool or the like feels wrong. It didn't feel right to be able to assign mappings to a key while erasing, and then continue as if nothing happened. With that said, having the sidebar visible, and being able to change the keymap while another tool is in use also feels a bit wrong.
So I have a third proposal: lets put the toolbox on the sidebar, below the overview, possibly on the same line as "Backup & restore", above "Modifiers". If a non-default tool is in use, then we can hide the floating key picker AND the sidebar below the toolbox, too.
This feels better than either on the floating picker, or on top. It does require some more thought, though, because for the color fill tool, having the palette available is helpful - but not the rest of the sidebar. So I need more fine-grained control here.
in the nearest future, I’m expecting to move more stuff from the side bar to the key picker and don’t think I’m going to want it hidden. On Oct 1, 2022, at 4:47 AM, Gergely Nagy @.***> wrote: I just tried to put this onto the floating key picker, and I hate it. :( Reason being, when any tool other than the default is in use, I'd love to hide the key picker, because its in the way. Having the key picker visible even when we're using an Eraser or Fill tool or the like feels wrong. It didn't feel right to be able to assign mappings to a key while erasing, and then continue as if nothing happened. With that said, having the sidebar visible, and being able to change the keymap while another tool is in use also feels a bit wrong. So I have a third proposal: lets put the toolbox on the sidebar, below the overview, possibly on the same line as "Backup & restore", above "Modifiers". If a non-default tool is in use, then we can hide the floating key picker AND the sidebar below the toolbox, too.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
Even if we move more stuff onto the picker (which I'm not entirely happy with, btw, it's already big and has a tendency to cover parts of the Model 100), I'm not convinced that the toolbox is a good fit there.
When erasing keys, I'd expect any and all assignment to be disabled - we're in erase mode, after all. Likewise for the paint tool: anything other than color assignment and palette changes should be disabled.
If we disable those, then it makes little sense to show them. If we don't disable them, that would, I imagine, would be confusing.
Perhaps there's a compromise, however: we could have a floating toolbox! Now, two floating things would be horrible, indeed, so we'd need to bind the toolbox and the key picker together. However, rather than putting the toolbox on the key picker, I'd attach the keypicker to the toolbox. This way they're moved together, scaled together, but we can still hide the picker if it's not useful, while the toolbox would remain visible.
can we step back a second and talk about what the expected use pattern of erase is? There are two things that I can expect to be common operations: “I want to erase this one key” and “I want to clear the layer”. neither of those really call for a sticky eraser. What common use case am I not thinking about?On Oct 1, 2022, at 11:18 AM, Gergely Nagy @.***> wrote: Even if we move more stuff onto the picker (which I'm not entirely happy with, btw, it's already big and has a tendency to cover parts of the Model 100), I'm not convinced that the toolbox is a good fit there. When erasing keys, I'd expect any and all assignment to be disabled - we're in erase mode, after all. Likewise for the paint tool: anything other than color assignment and palette changes should be disabled. If we disable those, then it makes little sense to show them. If we don't disable them, that would, I imagine, would be confusing. Perhaps there's a compromise, however: we could have a floating toolbox! Now, two floating things would be horrible, indeed, so we'd need to bind the toolbox and the key picker together. However, rather than putting the toolbox on the key picker, I'd attach the keypicker to the toolbox. This way they're moved together, scaled together, but we can still hide the picker if it's not useful, while the toolbox would remain visible.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
can we step back a second and talk about what the expected use pattern of erase is? There are two things that I can expect to be common operations: “I want to erase this one key” and “I want to clear the layer”. neither of those really call for a sticky eraser. What common use case am I not thinking about?
For both the Erase and Paint tool I have currently implemented, the use-case is that when they're in use, clicking a key will erase that key (set the keycode & palette index to defaults: transparent & 15), or paint it with the currently selected palette color, respectively. This allows one to selectively erase or paint multiple keys in a row, just by clicking on them. It's not a full layer erase / paint, nor is it a single key erase / paint - it can be used for that too, but the goal is to make it easier to erase / paint multiple keys without blowing the entire layer away.
Another approach, perhaps a better one, would be to allow selecting multiple keys (with, say, Ctrl held), and apply the paint / erase to those. Then they wouldn't need to be sticky. We could also implement other convenience things, like Ctrl+A selecting all keys, and copy & paste later.
On the other hand, doing that, supporting multiple keys selected would be a considerably bigger undertaking.
Current progress:
https://user-images.githubusercontent.com/17243/194784849-3f83e97a-3f8b-4cbf-92c5-08c5de6c8fdf.mp4
Not too happy about the opener, it feels too big. I'm thinking about detaching it from the toolbox itself, and turning it into a Fab.
Another idea to consier, circling back to @obra's floating keypicker idea: what if the key picker had a > icon in its top right corner, which would open the toolbox, attached to the picker? Not sure how I'd arrange the tools then, but that's also an idea I'll explore soonish.
A third idea: if we made the keyboard image a little narrower, we could put the toolbar at the (top) left side, always expanded.
Fourth idea! We could attach the toolbar to the sidebar, with an opener kind of thing. When opened, it would shrink the sidebar a little, and display the toolbar alongside it, vertically. The advantage of this is that this takes virtually no extra space.
This feels okay-ish, but having it embedded in the floating picker, resizing is busted. Placing it to the side makes it tricky to make the toolbox the same height as the key picker. I don't see it working out on the side, not really. So, back on top, and no hiding Keyboard104, that should work out better.
Is there a list of all the tools you're trying to find UI for on the page?
On Mon, Oct 10, 2022 at 2:58 AM Gergely Nagy @.***> wrote:
[image: Screenshot from 2022-10-10 11-53-56] https://user-images.githubusercontent.com/17243/194840510-ae2106d2-c058-434d-b5f2-8420541f49f1.png
This feels okay-ish, but having it embedded in the floating picker, resizing is busted. Placing it to the side makes it tricky to make the toolbox the same height as the key picker. I don't see it working out on the side, not really. So, back on top, and no hiding Keyboard104, that should work out better.
— Reply to this email directly, view it on GitHub https://github.com/keyboardio/Chrysalis/pull/1121#issuecomment-1273067979, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALC2BTQG7LXYEUZAMZADTWCPSFBANCNFSM6AAAAAAQZUPY3Y . You are receiving this because you were mentioned.Message ID: @.***>
Off the top of my head, I'd like to fit two groups of tools into the UI:
- Full layer operations: clear, copy, cut (both keycodes & colors), and painting all keys with a given color.
- Per-key operations (so instead of selecting the key for modification, we'd apply the selected tool's action instead): erase (keycode & colors), and paint (with color)
The use case for the per-key operations is that when you want to set up your colormap, and you want to color a group of keys by functionality, for example, then the current color assignment is a huge drag, and full-layer painting doesn't help, because we don't want to paint the entire layer, just 5-10 keys with the same color at a time. Same for erase: say, I'm trying a new layout, like Engram. I'm pretty solidly set on the alphas, but I'm still trying to figure out where to put punctuation and the like. In this case, being able to quickly erase some keys, without having to click the key, scroll to "blanks", then click, would be a huge help. I could create a layer with just the alphas, and copy that back, but... that feels like a terrible workaround, and it kinda breaks my flow of just staring at the layer and pondering.
I believe the best would be if we allowed selecting multiple keys at a time, because then we'd have no need for the per-key/full-layer tool distinction, as full-layer would just be a case of "Select all". However, that'd require a larger rework of the Editor, and I'd love to get these helpers to users sooner than that, hence trying alternatives that are easier to implement - even if the implementation is just a temporary measure.
"full layer" tools should all be clustered together near where we work with the current layer, in the top right corner.
The things you're describing as "per key operations" adds a new "modal" behavior to the edit ui. And other than "erase keycodes", both of the tools you describe are a variant of "paint" - It feels like the whole thing would be more intuitive and easier to work with if we broke the color stuff out into a full mode of its own.
On Mon, Oct 10, 2022 at 10:43 AM Gergely Nagy @.***> wrote:
Off the top of my head, I'd like to fit two groups of tools into the UI:
- Full layer operations: clear, copy, cut (both keycodes & colors), and painting all keys with a given color.
- Per-key operations (so instead of selecting the key for modification, we'd apply the selected tool's action instead): erase (keycode & colors), and paint (with color)
The use case for the per-key operations is that when you want to set up your colormap, and you want to color a group of keys by functionality, for example, then the current color assignment is a huge drag, and full-layer painting doesn't help, because we don't want to paint the entire layer, just 5-10 keys with the same color at a time. Same for erase: say, I'm trying a new layout, like Engram. I'm pretty solidly set on the alphas, but I'm still trying to figure out where to put punctuation and the like. In this case, being able to quickly erase some keys, without having to click the key, scroll to "blanks", then click, would be a huge help. I could create a layer with just the alphas, and copy that back, but... that feels like a terrible workaround, and it kinda breaks my flow of just staring at the layer and pondering.
I believe the best would be if we allowed selecting multiple keys at a time, because then we'd have no need for the per-key/full-layer tool distinction, as full-layer would just be a case of "Select all". However, that'd require a larger rework of the Editor, and I'd love to get these helpers to users sooner than that, hence trying alternatives that are easier to implement - even if the implementation is just a temporary measure.
— Reply to this email directly, view it on GitHub https://github.com/keyboardio/Chrysalis/pull/1121#issuecomment-1273635903, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALC2AWWID6PUT6XBQHEYTWCRISTANCNFSM6AAAAAAQZUPY3Y . You are receiving this because you were mentioned.Message ID: @.***>
And other than "erase keycodes", both of the tools you describe are a variant of "paint"
Technically, yes, erase is just "paint with defaults", but conceptually, I think they're different.
It feels like the whole thing would be more intuitive and easier to work with if we broke the color stuff out into a full mode of its own.
That's how Chrysalis did things originally (see screenshots in #116), but we merged the two in #322, because having them separate wasn't working out too well. I don't want to go back there. But having two modes on the same screen might be an option. I don't think it's a good one, though, let me explain why.
I still think that the best end-goal is to make it possible to select multiple keys, and apply operations to selected keys in bulk. This way, copy, cut, clear and paste wouldn't necessarily need any buttons on the screen, we could just use Ctrl-C, Ctrl-X, Del, and Ctrl-V as keybinds. Or have a small toolbar with these, which would Just Do What You'd Expect them to do. No distinction between color or key editing. We wouldn't need a paint tool either, because we'd just select the keys we want to change, and then pick a color from the palette. Thus, no modality at all required, and everything I want, and everything this PR is intended to solve, is doable without separate modes, without any kind of modality, or complicated tools. Copy, Cut, Delete, and Paste wouldn't be tools in this case, they'd be actions performed on the selection.
This is where I want to eventually end up at. But that's a lot of work.
I feel that breaking color editing out into its own mode would be inferior to the above experience. It would be an improvement over the status quo, for sure, but it wouldn't be as good as just being able to select multiple keys.
The reason I'm so adamant about pushing the toolbox is because it can be implemented reasonably easily, and we can deliver tools to our users pretty much now. It's not perfect. There are many other ways to deliver the same or similar functionality, that have a better UX. But all of those ideas - including breaking out the color editor into its own mode - is more work than the toolbox, and they aren't as straightforward from an UX point of view as multiple selection would be.
My goal here is to implement something temporary, and do it soon. If we're not okay with temporary solutions, then I'd rather start working on being able to select multiple keys, because that feels like a much better experience than breaking out the color editor into its own mode. (We also need to improve the UX of the color stuff, but that's a separate issue, imo)
I mean, even if we did break out color editing into its own mode, we'd still need to implement the tools to let people assign color in bulk (and it'd still be a button somewhere, to switch to color editing mode, not very different from the paint button, except for requiring a larger context switch, imo), pretty much the same thing this PR implements, but with a much more invasive change, both code and UI-wise, for little benefit in comparison.
Other than "erase" and color-related things, when do we want to multi-select keys? What are the actual user stories?
Message ID: @.***>
Other than "erase" and color-related things, when do we want to multi-select keys? What are the actual user stories?
- Moving a group of keys from one half of the keyboard to the other: when I was setting up my layout, I spent a lot of time trying to figure out which hand I want my mouse keys at, which hand I want my cursor, or my numpad. I ended up moving them around a lot. I ended up writing some custom JS code I could inject into a running Chrysalis that rearranged things for me (I didn't want to flash new firmware, wanted something faster).
- Swapping a group of keys (select a key, or a group of keys, drag them, drop them somewhere else). For example, moving the arrow keys on a layer from WASD to ESDF.
- Applying augmentation on multiple keys at once: select all (or some of) the modifiers, click "Sticky", voila, they're all oneshot now! Same for layer keys! Unlike exposing the "auto-oneshot" feature, this allows me to do this to some of the keys only. Eg, my Gui key is not oneshot, but the rest are, so auto-oneshot doesn't work for me. This can come in handy when you're experimenting. Similarly, to set up, say, the Programmer Dvorak-like "number" row, you would be able to lay out the numbers, select them all, and apply a "Shift" modifier to all of them in one action.
- Copying partial layouts from one layer to another. Lets say, I want to move mouse keys to a different layer. Their position is fine, I just want them on a different layer. With multi-select, I select, Ctrl-C, switch layers, Ctrl-V. Without multiple select, if the target layer isn't empty, I would pretty much need to re-assign the mouse keys one by one. With an empty target layer, I could cheat by copying the previous layer and erasing the parts I don't need, but that's also far less convenient than just copy & pasting a group of keys.
- When I rearrange my layout, I'd like the colormap to follow along. If we have bulk assignment, or some kind of easier assignment in color mode, that makes the coloring part easy. How do we make the key rearrangement part easy too? By making copy, paste, and drag-and-drop move generic. That requires multi-select.
There's probably a lot more stories where multi-select would be useful. I also think it makes much more sense to have copy & paste be a generic thing, along with erase.
Ok. That's super-useful.
On Mon, Oct 10, 2022 at 11:59 AM Gergely Nagy @.***> wrote:
Other than "erase" and color-related things, when do we want to multi-select keys? What are the actual user stories?
- Moving a group of keys from one half of the keyboard to the other: when I was setting up my layout, I spent a lot of time trying to figure out which hand I want my mouse keys at, which hand I want my cursor, or my numpad. I ended up moving them around a lot. I ended up writing some custom JS code I could inject into a running Chrysalis that rearranged things for me (I didn't want to flash new firmware, wanted something faster).
- Swapping a group of keys (select a key, or a group of keys, drag them, drop them somewhere else). For example, moving the arrow keys on a layer from WASD to ESDF.
- Applying augmentation on multiple keys at once: select all (or some of) the modifiers, click "Sticky", voila, they're all oneshot now! Same for layer keys! Unlike exposing the "auto-oneshot" feature, this allows me to do this to some of the keys only. Eg, my Gui key is not oneshot, but the rest are, so auto-oneshot doesn't work for me. This can come in handy when you're experimenting. Similarly, to set up, say, the Programmer Dvorak-like "number" row, you would be able to lay out the numbers, select them all, and apply a "Shift" modifier to all of them in one action.
- Copying partial layouts from one layer to another. Lets say, I want to move mouse keys to a different layer. Their position is fine, I just want them on a different layer. With multi-select, I select, Ctrl-C, switch layers, Ctrl-V. Without multiple select, if the target layer isn't empty, I would pretty much need to re-assign the mouse keys one by one. With an empty target layer, I could cheat by copying the previous layer and erasing the parts I don't need, but that's also far less convenient than just copy & pasting a group of keys.
- When I rearrange my layout, I'd like the colormap to follow along. If we have bulk assignment, or some kind of easier assignment in color mode, that makes the coloring part easy. How do we make the key rearrangement part easy too? By making copy, paste, and drag-and-drop move generic. That requires multi-select.
There's probably a lot more stories where multi-select would be useful. I also think it makes much more sense to have copy & paste be a generic thing, along with erase.
— Reply to this email directly, view it on GitHub https://github.com/keyboardio/Chrysalis/pull/1121#issuecomment-1273699539, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALC2CH4GXBMTUP3JYCRSLWCRRQTANCNFSM6AAAAAAQZUPY3Y . You are receiving this because you were mentioned.Message ID: @.***>
doing it for color is one thing. Key code, I still don’t understand when someone would want to be doing this.On Oct 1, 2022, at 4:24 PM, Gergely Nagy @.***> wrote:
can we step back a second and talk about what the expected use pattern of erase is? There are two things that I can expect to be common operations: “I want to erase this one key” and “I want to clear the layer”. neither of those really call for a sticky eraser. What common use case am I not thinking about?
For both the Erase and Paint tool I have currently implemented, the use-case is that when they're in use, clicking a key will erase that key (set the keycode & palette index to defaults: transparent & 15), or paint it with the currently selected palette color, respectively. This allows one to selectively erase or paint multiple keys in a row, just by clicking on them. It's not a full layer erase / paint, nor is it a single key erase / paint - it can be used for that too, but the goal is to make it easier to erase / paint multiple keys without blowing the entire layer away. Another approach, perhaps a better one, would be to allow selecting multiple keys (with, say, Ctrl held), and apply the paint / erase to those. Then they wouldn't need to be sticky. We could also implement other convenience things, like Ctrl+A selecting all keys, and copy & paste later. On the other hand, doing that, supporting multiple keys selected would be a considerably bigger undertaking.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
With the new editor UI, this branch is obsolete, so I'm closing it out. The idea of extra tools is still 100% valid, though.