Autobuilder & Tracker offline
After 10 years of service, the PC running Doomsday’s autobuilder VMs has died. Probable culprit looks like the PSU, so I’ll replace it with a new one and (fingers crossed) the machine can still be resuscitated to full working condition. In the meantime, there will be no new unstable builds. Fortunately the AppVeyor and Travis CI builders should keep the boat afloat until the autobuilder is up and running again.
Another casualty of this hardware failure is the bug/feature tracker that was running on the same PC. The tracker will likewise be offline for now.
Focus navigation
Recently I’ve been working a lot on UI focus navigation. The ultimate goal is to allow using Doomsday without ever touching the mouse, i.e., with only the keyboard or a gamepad.
It is good to note that overall, Doomsday’s UI has been primarily designed for mouse-based use on a traditional desktop/laptop computer. As such, key-based navigation in this design should be considered a fallback. It is possible that at some point in the future, the UI could be modified to be more “console-like”, but at least in this desktop version of Doomsday it makes the most sense to have a mouse-first GUI.
There are now two basic ways to move the flashing focus indicator around: Tab and arrow keys. The Tab key (also Shift+Tab) moves the focus in the widget tree based on the logical structure of the UI. Arrow keys move the focus according to the on-screen placement of the widgets. The focused button can be clicked with the Enter or Space keys.
Whenever a popup is open (including smaller popups like menus and larger ones like dialogs), focus navigation is confined within the popup. The Esc key can be used to close the currently open popup.
While this is rather pedestrian a feature, there were a couple of interesting details. For example, with arrow key based navigation, the focused widgets need to be chosen algorithmically since the placement of widgets may change on screen. Also, because the logical structure may be quite different from the visual arrangement, one needs to consider all of the visible widgets when choosing the next one to focus. The algorithm I’ve ended up with considers the following details:
- Widgets that have shared edges.
- Having a common parent.
- Overlapping positions along the desired movement direction.
- Angle between the movement direction and the positions of the widgets.
While the current implementation is starting to work adequately, there is always room for improvement. Perhaps the most significant missing feature is that if the focus is for any reason cleared, the only way to get it back without using the mouse is to open the console. The Home UI also needs further input focus fine-tuning so that arrow key navigation feels less haphazard.