Make interface more keyboard friendly #277
Comments
(relates to #277) By default, PD automatically sets control tab order using left-to-right, top-to-bottom ordering. On individual adjustment and effect dialogs this works very well, and it ensures tab order is correct without me needing to manually program it for all 100+ windows. However, there are some windows - like tool options on the main screen - where the default order doesn't match the ordering of these controls, typically because option windows are heavily space-constrained. As there's no easy way to handle these tool option windows automatically, I've added a new workaround. Controls now receive notification when tab/shift+tab has been pressed, and they have a chance to override the default ordering with their own custom ordering instead. This feature can be fully ignored and PD will revert to its old behavior, so it adds no penalty to the existing automatic solution. Instead, it provides me a way to fix tab order on windows with specialized layouts. Thank you to @schneis for first reporting this.
(Relates to #277.) The move/size tool options panel now uses custom code to handle much of its tab-key ordering. Controls on this panel are grouped vertically (instead of horizontally, like most PD windows) - a deviation that makes me wonder if perhaps the panel needs to be reorganized to match other patterns. I'm mulling this over. In the meantime, tab-key ordering (inc. shift-tab-key) is now much more intuive on this panel. Thank you to @schneis for catching and reporting.
|
Thank you for this excellent feedback, @schneis. These kind of small details are incredibly easy for me to miss, and it's a huge help when users provide concrete usability feedback like you have. There are several different issues at play here - some easy to solve, others more complicated - but I'll work on addressing all of them as quickly as I can. First up: I've just committed a series of improvements to tab-key ordering. PhotoDemon is built on a custom UI kit that - as you point out - heavily focuses on mouse usage. Keyboard interactions still need some work! Fixes I've just uploaded include...
Hotkeys is a messier problem to solve, as it really needs a full-blown customization tool that allows users to set their own shortcuts. (Trying to implement a default one is not easy, as PD is available in so many different locales.) This has been on my to-do list for awhile but there are a lot of messy details I have yet to work out. If you know of other software that handles this feature well, I'd love to investigate them to gain a better understanding of the work involved. Thank you! |
Relates to #277 Various button-type controls now better reflect their focus and navigation state when the user navigates them using the keyboard. This includes clearer communication of when these controls have received (and lost) keyboard focus.
|
Over a year later, I'm back with an update! 😱 Many improvements have been made in this area over the past year, most of which I (unfortunately) forgot to tag against this commit. For example, all menus are now navigable by keyboard, regardless of your current language - PD automatically generates these "mnemonics", as Windows calls them, at run-time. So using the original example of "Crystallize", (Also, the Crystallize filter is much faster and has tons of new features in nightly builds, so that's fun!) Tab key navigation is now available on all dialogs, too, and various UI elements now display keyboard focus much better. (You can also do convenient things like move spin control values up/down using up/down keys, even if you're in the text section of the control.) My last major keyboard-related fix is custom hotkeys, which is high on my to-do list. I hope to have this available before the next major release. Once this is ready for testing, I'll update it in its own issue since it's quite a large endeavor. Thank you again for prompting me to take keyboard interactions more seriously, @schneis ! If anything in the current nightly builds remains unintuitive, please let me know and I'll get it fixed. |
The program is really cool, but requires a mouse for even simple things. Making better use of the keyboard would really improve usability.
One example - the Move & Resize tool ... select the Layer position X field, press Tab - the next control selected is the Layer size width up/down buttons (not Layer position Y input box which would make more sense). Tabbing between the fields always selects the up/down arrows and not the numeric value making the keyboard almost useless here.
Another example - the menus do not all have hotkeys to select them. I frequently use Effects -> Pixelate -> Crystallize and only Alt+C is available to open the Effects menu. Being able to do something like Alt+C, P, Y to open Crystallize or being able to define my own hotkey (eg Ctrl+Y) would be very useful.
The text was updated successfully, but these errors were encountered: