New API to read Caps-Lock and Num-Lock state

[Kevin Rushforth]

Hi Jonathan,

Thanks for the suggestion. I thought about it as well. We could do that, 
but it seems like overkill. I'll reconsider if enough others favor the 
idea. As for the exception, my thinking is to use 
UnsupportedOperationException, which is what the equivalent AWT method 
uses. FWIW, I don't generally like checked exceptions; we don't define 
any such exceptions in JavaFX and I wouldn't want to start now.

-- Kevin


On 1/16/2021 12:46 AM, Jonathan Giles wrote:
> Hi friends,
>
> Just to throw out an alternate API approach (which I would not go 
> anywhere near close to saying is a better approach), we could consider 
> a three-value enum getter API:
>
> public static KeyLockState Platform::getKeyLockState(KeyCode keyCode);
>
> Where KeyLockState = { LOCKED, NOT_LOCKED, NOT_PRESENT }
>
> I'll be the first to argue against yet another enum, but I wanted to 
> throw this out there as an alternate approach that avoids the needs 
> for checked exceptions (which is what I assume is meant by 'throw an 
> exception', as opposed to throwing a runtime exception).
>
> -- Jonathan
>
> On Sat, Jan 16, 2021 at 6:40 AM Kevin Rushforth 
> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
>
>     For JavaFX 17, I am planning to add a minor enhancement to read the
>     state of the keyboard lock keys, specifically, Caps-Lock,
>     Num-Lock, and
>     maybe Scroll-Lock (although I might defer the latter to a future
>     version
>     since it will be more difficult to test, and doesn't seem as useful).
>
>     This is currently tracked by JDK-8259680 [1].
>
>     The proposed API would be something like:
>
>              public static boolean Platform::isKeyLocked(KeyCode keyCode);
>
>     One question is whether we should throw an exception if the key state
>     cannot be read on a particular system (e.g., Num Lock on macOS),
>     which
>     is what the similar AWT API does. I don't have a strong opinion on
>     that
>     poont, although I wouldn't want to throw an exception if the keyboard
>     doesn't have the key in question, as long the system is able to
>     read the
>     state accurately.
>
>     Comments are welcome.
>
>     -- Kevin
>
>     [1] https://bugs.openjdk.java.net/browse/JDK-8259680
>     <https://bugs.openjdk.java.net/browse/JDK-8259680>
>