Page MenuHome

Handling Numpad keys dependent on Num Lock state
Needs ReviewPublic

Authored by matc (matc) on Mon, Aug 12, 2:18 PM.

Details

Reviewers
None
Group Reviewers
User Interface
Summary

Using event->ascii to distinguish between Num Lock states. When Num Lock is off, there is no ascii character associated with the numpad keys. This works with ghost SystemWin32, SystemX11 and should work with SystemCocoa (as it is assigning utf8[0] to ascii). Ghost SystemSDL needs a small patch because of the hardcoded keyboard layout.

This patch adds two options to the Input section of the user preferences. "Ignore Num Lock" is enabled by default, to avoid changing default behaviour. When it is disabled the numpad keys behave like Home, End, Insert, Delete, Page Up, Page Down and Arrow keys (Note: Enter, +, -, *, and / are not affected by this patch.). The second option is "Custom Numpad Keys" which will map the keys to a newly defined set of keys. This allows to avoid having two keys of each.

Example:
With default settings Numpad 7 will always show up as Numpad 7 in the keymap editor. With "Ignore Num Lock" disabled, it will show up as Numpad 7 or Home. With "Custom Numpad Keys" enabled, it will show up as Numpad 7 or Custom 7.

With respect to text editing when Num Lock is off, the numpad keys can not be used to write numbers, independent of all settings.

Diff Detail

Repository
rB Blender

Event Timeline

matc (matc) created this revision.Mon, Aug 12, 2:18 PM

Does anyone else from the user interface team have an opinion on this?

Personally I wouldn't expect viewport navigation shortcuts depending on numlock, so leaving that behavior the same by default seems right to me. A preference helps a little bit, but of course does not solve the confusing default behavior with someone that has a keyboard as in the bug report.

The custom numpad keys preference seems too obscure to me, I wouldn't add it.

If Blender were primarily a text editor or IDE, this would make sense (some users prefer these keys for navigation - arrow keys, page up/down, home/end).

However, it has been this way for many years and I don't think this helps to use num-lock in almost all cases.

Num Lock would essentially allow to switch between viewport and keyframe navigation. Probably more useful on laptop keyboards with squished arrow keys.

The custom numpad keys were initially thought as one way to avoid the focus/delete problem for numpad period. Although this can be done way simpler.

Could the custom numpad keys may be useful for addons? Or is there already a way to do this?

No strong opinion, other than what @Brecht Van Lommel (brecht) says. Since you aren't typing numbers, I'm not sure this makes sense for view manipulation.

I'd be in favor of letting users treat numlock/capslock states as (optional) modifier keys. It'd be more in-line with user expectations and it would produce fewer unexpected behaviors than what's proposed here.