When I created the mouse layer, I was thinking about adding a boost key to increase the pointer movement speed while it's pressed. It'd allow for faster navigation when large distances need to be traveled by the pointer. I also immediately thought of the left Mod key as the ideal candidate for this purpose. Shortly, I dismissed my idea thinking that Mod is a layer switcher key, and as such, it should only serve one purpose not to overcomplicate matters.
Lately, we've been contacted by two of you, independently suggesting to add a feature akin to my original boost concept. I honestly cannot remember the name of the first person, but I can clearly remember the second of you, Christian Léger, who has suggested not only to enable users to increase mouse speed but also to decrease it for finer-grained mouse interactions. At first, I was a little hesitant, but ultimately, I do think that acceleration and deceleration complement each other very nicely and improve usability, so hence here's the updated mouse layer.
Given the normal, user-configurable speed of the mouse pointer, the accelerated speed can be 2x, and the decelerated speed can be 0.5x of the normal speed, for example, all being user-configurable values.
But there's an important question to be answered: What if both the Mouse and Mod keys are pressed simultaneously? Which layer switcher key should dominate choosing the layer to be used? Easy: let's put the layer switcher keys into a priority list, defaulting to Fn, Mouse, and Mod. I'm not fully confident about the exact order, but in any case, the UHK being a fully configurable keyboard, this priority list will be configurable on a per-keymap level.
Update (2016-07-29): We'll ditch the priority list in favor of a much easier solution: Whichever layer switcher key gets pressed first will be the active one (active layer) until release.
I've also made some other fixes. First of all, I added "button 6", which was missing. Second, I replaced "history prev" with "button 4" and "history next" with "button 5". The original naming of these keys was based on the function of those keys within browsers, but the more generalized naming is clearly better.
We're infinitely grateful for people like Christian who have taken the time to share their thoughts. Believe it or not, even when you ask questions quite often, you make us learn and sometimes reiterate our design. This blog post is the evidence that you can make a change, and we're listening to you. Let's push things further than ever and make the Ultimate Hacking Keyboard a truly remarkable keyboard!
2 Comments
There's only thing I don't like about the mouse layout as I see it. Why the dead key between the mouse key and the click keys? It would seem to me that if one is using the mouse layer, it is likely to be used for a decent while, and it would make more sense to shift the hand one key left to avoid stretching the pinky. There's nothing else to reach for in the left hand on the default mouse layer, so I can't see any benefit to the stretch. If you are in typing mode, chances are very high that the mouse is not sitting where you want it - and may even be hidden by your editor to avoid distracting you.
I know I can remap it, so it isn't a big deal, but having the labels in the right location would be nice if you haven't printed them yet. Hmmm... are the mouse functions unprinted, and thus it doesn't matter?
The mouse layer are unprinted, indeed. Only the base layer and the mod layer are printed.
The Mouse buttons have been placed, so that the user doesn't have to leave the home row. Regardless, your logic does make sense to me. Luckily, it's very easy to reconfigure the layout, just as you noted.
Comments are closed.