Over the past couple of months, we've introduced numerous improvements and fixes for Oryx. Let's take the time to review some of the bigger ones:
Welcome screen redesign
We've created a new welcome screen, to quickly explain what Oryx does, showcase all our supported keyboards, and allow people to create an account or log in as they get started. As before, you can still use Oryx anonymously — an account is not required.
Search revamp
We've overhauled search from the ground up. We now use Elastic behind the scenes, so searching layouts using tags is incredibly fast (try it!). There is also a checkbox that lets you browse all layouts that have Layout Tours — a great way to get started.
Account page redesign
The new Account page allows people to secure their account using 2-factor authentication (2FA), as well as (finally) change their email address. It's also tidier.
Custom labels for keys
Got a key that sends Cmd+S? Go ahead, label it "Save" right on your layout. This also helps with keys that send special characters (see the next item), macros, and more. There's a simple toggle to switch all the custom labels off, so you can see the underlying keystrokes.
You can also now label keys with an icon if you prefer.
Custom symbols using macros
Would you like a single-tap ♥ key on your board? How about an Ö key that works even when your operating system is expecting input in English?
All this and more is possible with Unicode input. Depending on your OS, there are different ways to use Unicode, but now that Oryx supports 5-character macros, you can automate them all.
Windows
Unicode on Windows is commonly referred to as "Alt codes" because they are done by holding the Alt modifier key. By default, Windows uses decimal input (as opposed to hexadecimal) for Unicode. This isn't that important to understand, but just remember if you're looking up how to enter special characters with Unicode on Windows, make sure to refer to the decimal codes.
With a regular keyboard, you can hold down the Alt key, tap a special sequence of digits on your numpad, and let go of the Alt key: A special character then appears on your screen.
With Oryx, you can now automate this to a single tap:
- Go to Alt Codes and look up the character you'd like to use.
- In Oryx, create a macro with those digits. Be sure to select the Numpad version of each digit, "num 1" and so on.
- Make sure Num Lock is toggled on.
- Tick the box that says "Hold Alt pressed (send Unicode)".
That's it! When you next compile and flash your layout, this single key will give you the special character you specified, regardless of your operating system locale.
macOS
On macOS, you'll instead want to refer to the hexadecimal Unicode. To use Unicode on macOS, you will need to switch your OS keyboard to "Unicode Hex Input". This is like a typical QWERTY layout, but when you hold Alt, you'll be able to enter a hexadecimal code and the appropriate character will appear once the code is completed (no need to hit Enteror anything).
It is important to note that macOS limits the hexadecimal input to the Basic Multilingual Plane, so you'll be able to enter pretty much any character from another language, but emojis and such are off the table using this method. Technically, it is possible to enter emoji and similar characters' hexadecimal codes as well, but it is significantly more complicated and not something you can automate with Oryx macros.
Linux
Linux has a couple of different ways to enter Unicode, but the most common method involves holding Ctrl + Shift, hitting u, entering the hexadecimal code, and finally releasing Ctrl + Shift or pressing Enter.
You usually can't fit this sequence on a single macro in Oryx, but you can fit it into two. If you create a Ctrl + Shift + u key, then create your Unicode macros and end them all with enter (maybe put these all on their own layer), you will be able to access tons of characters using just a short two-key sequence.
Unicode Disclaimer: While Unicode is extremely flexible, its flexibility comes with somewhat tedious setup and specific use cases. If you primarily type in one language but occasionally need some characters from another language, Unicode can be a great help. However, Unicode is not a great replacement for more complicated multi-lingual setups unless you are willing to spend a lot of time setting it up and practicing where all your key placements are. For more information on international layouts, see our International Setup Guide.
Unblocking LT/MO in destination layer
By default, when you have a Layer Toggle (LT) or a Momentary Toggle (MO) key leading to a certain layer, we do not allow you to reassign that key in the destination layer. It's reserved, because you're going to need it to get out of the layer.
However, what if you have two different keys leading to the same layer? In this case, you could use this advanced setting and allow yourself to reassign those keys.
Animation tweaks
We've made the default animation speeds on the boards slightly slower, and added two new keycodes which allow you to control the speed of animation on your own board with just a tap.
Housekeeping and dependencies
Behind the scenes, we’ve made a number of changes to clean things up and keep them speedy. The priority was to update Oryx's dependencies on both the frontend and backend. We've updated front-end dependencies (React, mobX, Apollo), and then back-end dependencies (Ruby, Rails, GraphQL-Ruby).
Previously, we used Docker to run Oryx's backend. It was overkill. By switching to good old Capistrano and Puma, not only did our CI/CD process go down from 8 minutes to 50 seconds on average, but we also removed a lot of infrastucture. Goodbye, Docker Swarm. Farewell, private Docker registery.
We did keep Docker around for one thing: Compiling firmware. Using a custom Alpine image, we are able to set the exact versions of gcc-avr and gcc-arm-none-eabi. By updating our gcc binaries from 7.x to 8.x we saw a signicant size decrease in the firmware produced, allowing people to do more with their keyboards (more complex firmware, more layers, etc).
At some point in the midst of all of this, we started observing memory usage creeping up on our server. Oh no, a memory leak! Updating Ruby and dependencies did not help. After some serious head scratching, we found out that what we were observing was memory fragmentation rather than a leak.
Originally when pulling data for a layout, we would also grab the 10 latest revision for that layout including all the layout's layer and key mappings. That's a lot of data! We found out that memory fragmentation was happening when serializing those large data objects to JSON before sending them back to the browser. We refactored the layout data fetching by reducing the amount of data fetched and implemented lazy loading. Memory usage for one instance of Oryx's backend went down from 4GB to an healthy 400MB. It also significantly improved loading speeds for layouts in the browser.
We took this opportunity to improve how layouts data is updated, too. Before, with every change to a key (mapping, color or label), we would update the layer data and send the whole layer payload to the server (with a debounce, to avoid sending two consecutive quick updates). By only sending the updated key data and by batching the updates so that if several keys are updated quickly, we avoided race conditions and made updates more reliable.
Moonlander support
Finally, we've also unveiled complete support for the Moonlander. :) The Moonlander has been merged to the upstream QMK Firmware repo and is fully supported in both Oryx and the QMK configurator.
Updated April 2023 by Robin Leinonen
