-
Notifications
You must be signed in to change notification settings - Fork 108
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
Painting with keyboard #22
Comments
I'm planning something similar to this with "visual" mode 👍 |
Yes. This is exactly what I thought the tool was capable of. This could be a game-changer. Let me know if you need testers/contributors. |
Any update on this? |
Visual mode is now in master - try it out! You can fill the current selection with |
|
Just stumbled on
This is from a very early prototype for such an editor I wrote a few years ago: So essentially the editor also had the goal of being Vi-like (named "vixel"), but with a keyboard-only focus. In the image above, drawing pixels is done by holding space (or some controller button) and the color selection is done by holding What I had in mind there was optional controller support, so you select the color via shoulder button, pick a color and release the button or push another controller button to fold out the color into another "ring" of subcolors - all that while holding the shoulder button. Now I'm not sure whether this is a sensible approach to this (after all it was a PoC), but it did allow to select colors more quickly than eg. by scrolling through the palette one-by-one. Also, since |
Hey @aszlig - thanks for the inspiration! Keyboard painting is not a super high priority right now, but I think your approach is interesting. I've actually been wanting to implement keyboard-based color selection regardless of whether you use the keyboard to paint, as I think it could be in many cases faster than moving your cursor to the palette and back. |
It would definitely be nice to see this. The current design feels odd, tbh. Vim-like keybindings are simply a poor fit for the mouse/tablet + keyboard workflow model, because they were designed with the expectation that the user will have both of their hands on the keyboard at all times. Most digital artists who work with this kind of setup usually cramp most of the keybinds all the way to the left (i.e. non-dominant hand) area of the keyboard. This way they don't have to release their mouse/pen just to reach a keybind. |
It would be great if a user could control brush with keyboard, instead of frame. Maybe it could be done in modal fashion like vim. Right now it doesn't make sense to use hjkl when you need to use mouse at the same time.
Also it would be great if you could map specific keybindings for creating specific patterns, maybe through scripting language or just with libraries of images.
The text was updated successfully, but these errors were encountered: