That’s because there is no localised Dvorak for Hungarian that I could find.
I have used Hungarian QWERTZ in the past, and while it made inputting Hungarian a tiny bit easier, I lost easy access to other symbols I use more often. So I’d have to mix a localised layout with macros or somesuch, to have both my [] keys, and the accented symbols with similar ease. I would still need to place the Hungarian symbols somewhere, and if I put it on a layer, then from a usage point of view, it does not differ at all from using a one-shot layer. Yes, the scancodes sent are different, but I’m tapping the very same physical keys. I don’t really care what scancodes are sent, I’m more interested in how to get to the point where the scancodes can be sent.
The scancode to send is easy to change. Figuring out when to send them is harder.
I hope this makes it clearer why I’m dismissing OS layouts.
Having alternate ways to input localised symbols does not make it impossible - or even hard - to use OS-side layouts. For my use case, and I imagine, for a number of others, the OS layout is limiting: you gain localised symbols, and lose easy access to others, which becomes a problem when the lost symbols are used more often. In that case, you will have to find a way to make them easier to input, and you’re back on square one, just looking at the same issue from a different angle.
Yes, there is Hungarian QWERTZ, available on all major OSes, with which you can type all the funny symbols without any modifier or magic. But they reuse scancodes used by other symbols used on US-QWERTY: ő replaces [ for example, and so on.
So it is a bit of a trade off, and for my use cases, one I’m not happy to make, because I use [ more often, thus, I’d end up hiding ő in a layer anyway. Thus, in both cases, I’d press the exact same physical keys, but end up with different keycodes sent. From my point of view, scancodes are irrelevant, I want the physical access to be easy. What magic the computer has to do to make it work, doesn’t matter. It’s a computer, it can do magic faster than I can tap keys, so I let it do its thing.
But I’m not an average user, I have not used a localised layout in more than a decade. Thankfully, these things we discuss here, can work alongside an OS layout just fine, if so need be. :]
This is exactly my point. It is a tradeoff that you are willing to make. But not everyone will come down on the same side of that tradeoff. There are a lot of people who prefer US_ASCII over their localised layout (including me!). But there are another lot of people who do not. Both must be considered.
Yep. Which is one of the many reasons that all ideas considered here are to be implemented as small, composable libraries, and not the default behaviour of the stock firmware.
Unfortunately, I don’t have the time to really keep up with this conversation, and I lack the keyboard-hacking experience necessary to completely understand all the details, but I do have a pretty good idea of what I want from my Model 01, so I thought I’d share.
First: I want to be able to plug my keyboard into any computer and have it behave the same regardless of the OS. I don’t want to have to install any customizations on the target computer, and ideally I wouldn’t have to configure it to use a different keyboard layout than what is automatically detected. Therefore, I want almost all customizations done in the keyboard, not the OS. I’m guessing that this will require different modes in the keyboard for different operating systems. Ideally, the keyboard would be able to both tell the OS what type of keyboard configuration it should use, and also detect which OS it’s connected to, so it could put itself in the correct mode, but it wouldn’t be so bad to have to use a key combination to switch OS modes (as long as that mode persists through power cycles).
Second: The Model 01 is radically different from any keyboard I’ve used before, which is one reason that I want it. I touch-type on QWERTY keyboards, but I don’t like that layout at all. I plan to use something Dvorak-ish, and I think there’s a good chance that learning to type my custom layout on the Model 01 will not interfere with my ability to type on other (QWERTY) keyboards (learning to use a MessagEase keyboard on Android hasn’t had any effect, for example). To this end, the more different it is from other keyboards, the better.
Third: I want to be able to separate shifted and unshifted characters. I thought about trying the Truly Ergonomic Keyboard, but found that the keyboard-remapping tool was too limited — I could shift keys around, but there was no way to have (for example) [backslash] and [pipe] on different keys.
Fourth: I’m not a fast typist, nor do I really care about speed and efficiency. I mainly want to improve accuracy and eliminate awkwardness. I’m probably very different from most people here in that I have never had any hint of RSI trouble, perhaps because I move my whole hand rather than stretching fingers to reach keys that aren’t near the home positions. My chief worry about the Model 01 is that it might cause an RSI by giving me more reason to keep my hands stationary…
Fifth: I want to be able to input non-ASCII characters easily and reliably with some kind of Compose key, where I can customize the particulars. I type French often enough that I want to be able to do it easily and reliably, but not so often that I care about how long it takes to do it (three keystrokes for every é is acceptable, but having it only work sometimes is very frustrating).
Sixth: I expect to make use of most of @algernon’s new functionality, but as I lack experience in that area, and also lack the free time to learn it quickly, I’m not going to finalize anything until I get my hands on the hardware and some sort of tutorial for reprogramming it. I’d say that the thing I want most from the firmware is good documentation for people who have never done firmware programming before.
For some of the things, yes. For the basic functionality, thankfully no.
Sadly, the keyboard can’t reliably tell the OS which layout to use. But as long as you have the same layout on all computers you want to use the Model 01 with, you’ll be fine.
Similarly, it can’t ask the computer what OS it is running, either. There are hacks that help with guessing, but that’s just that: a guess. A reasonable default, but it must not be the only thing to rely on. So a key combination to set the mode on the keyboard itself will likely be needed. That can be persisted to EEPROM, so that the keyboard remembers the setting across reboots.
So, in short, your first requirement is easy to satisfy, and is pretty much how the keyboard will function by default. (Minus the OS guessing and remembering thing. The stock firmware is - I believe, but @jesse will hopefully correct me if I’m wrong - not going to have anything very OS-specific.)
This is possible with the core firmware already, yay!
This is the toughest one, I believe. If you are okay with using a different way to enter those symbols depending on the OS, then the core firmware is enough. I only know how to do the compose stuff on Linux, but from what I understand, OSX and Windows do it differently.
It is possible to hide the details within the firmware, so you can use the exact same sequence of physical keys on all three operating systems, but for that, you’ll have to set the mode. Doable, with my set of plugins.
Good guides, tutorials and the like will be there, by the time the keyboard ships. I have my wife’s promise that she’ll be the guinea pig, and the docs will be written so that with their help, she’ll be able to use the plugins too, and reprogram the keyboard. (She’s as far from being a programmer as you can be.)
Of course, the plugins being free software too, the guides will be in the repo too, and any review, critique, and comments will be most appreciated
(And I’ll add a link to the repo to the original post in a minute.)
That’s about what I expected. Using a key combination to do a mode switch when first plugging in to a computer is no problem, but having to do it at every powerup would be a nuisance.
I definitely want the same compose behavior regardless of the host OS, so it would need to be in the firmware. Maybe your unicode input features would be the way to go, if we can figure out how to do it right for each OS?
I will be happy to contribute to your guides, if I can; you’re almost certainly going to save me a huge amount of time that I was expecting to spend learning to program the firmware myself in order to get the behavior I want. =)
I’d really like to have chording light up. When using something like vim or emacs it would be great to have chords light up only the keystrokes that can follow the current sequence.
I really wish we could have key caps with colored translucent sections, so that we could press a modifier and only the appropriate legend would light up based on the back-light
I assume this sort of thing would require that the editor be able to communicate with the keyboard to indicate its state. If there is such an API, I’d be up for writing a vim library to do so!
Edit: where by vim, I probably mean neovim (I have not heard great things about vim 8’s job API)
Some nice LED animation scripting would be cool. Being able to define “curves” that can have colors mapped to them for certain key sets is a thought. Let’s say I use a notation of “{A, B, C, …}.r = sin(t)” - this would animate the red value of keys A, B, C, etc. using a sine function over time. You could get fancier by defining your own mathematical equations. If I were to keep that notation, swizzling like shaders do would be neat (i.e. {A}.rgb = {1, 2, 3}).
Another thing I definitely want is rainbow ripple effects when I type. Pressing a key would generate a colorful ripple outward across surrounding keys. Not particularly useful, but seems fun to make.
Most of all, I desire a Lua interface to the API that allows me to upload scripts via serial for simple yet robust adjustments to the firmware on the fly. That’d be the most useful IMO since it would make it even more trivial to safely make changes to the firmware. If no one else is doing this I’ll add this myself. One could make entire libraries in Lua and use them to manipulate the firmware.
This requires assistance from the editor. It is - in theory, at least - possible to communicate with the keyboard via USB serial, and it would be nice to have a common protocol to communicate with the keyboard. That’s a tough cookie, however, and isn’t something we can realistically do by the time the keyboard ships.
It’s a good idea nevertheless, something I wanted to explore too. Will add it to the list
We don’t have to communicate back and fourth if the keyboard could take a chords file or something like that as part of the firmware. That would require work to create the file and update it that wouldn’t need to be there if we can send messages down USB.
This, I can do, I think. I wanted to do something similar (but simpler). It’s not terribly hard.
Do you mean a Lua interpreter within the firmware? That’s not going to work: there’s not enough space (especially for data) on the keyboard for that: there’s about 28k available for the firmware, and 2k for data. About half of both is already in use by the default firmware, and even if you strip it down considerably, we are still looking at ~14k of code, and slightly more than 1k of data already used. Squeezing Lua into that tiny amount is not going to work well.
Now, if we had a Lua library that emits C code, that would be a whole lot different, and entirely doable. The LED effect APIs are - in my opinion - pretty versatile and flexible.
Scripting is - sadly - non trivial, not if we stick to the firmware only. Tools that help generate C code could make things simpler, but at the moment, that’s way out of my scope. I’d play with such a tool, would one be available, though.
In my experience it’s almost impossible to really know the modes of the editor without communicating with it, for example what if you unplug your keyboard, put your laptop to sleep, disconnect the terminal, etc.
