Re: New API to read Caps-Lock and Num-Lock state
I also think that the suggestion of using Optional is a very
good one, and more clearly expresses the "unknown" case without having
to invent a new enum and without the problems that throwing an unchecked
exception could cause.
Thanks.
-- Kevin
On 1/18/2021 12:20 AM, Nir Lisker wrote:
Looking at the use case for this request, which is to warn the user while
typing in password fields, I tried to write some simple code for it using
the Optional approach:
Optional result = Platform.isKeyLocked(KeyCode.CAPS+LOCK);
result.ifPresentOrElse(on -> label.setText("Caps Lock is " + (on ?
"on" : "off")),
() -> label.setText("Check Caps Lock"));
In practical terms, a key event listener would need to be added to the
password field to react to Caps Lock presses, and that will call the code
above.
I think that this is the best option.
On Sun, Jan 17, 2021 at 8:10 PM Frederic Thevenet
wrote:
I realize that my suggestion was somewhat unclear, apology about that.
I wasn't suggesting that we return null to count as the third state, but
indeed that we leverage the isPresent state of the optional, alongside
with the two states provided by the Boolean, e.g:
isKeyLocked(KeyCode.NUM_LOCK).ifPresent(locked-> {
// The num_lock key exists on the current platform
if (locked){
// React to the key being locked
} else {
// Or to the key not being locked
});
On 17/01/2021 18:31, Jonathan Giles wrote:
A method returning Optional should never return null, as that undoes
the contract that Optional is supposed to represent, which is to avoid
NPEs by never being null itself, only empty in the absence of a
returned value. For this reason, an Optional should be considered two
state rather than three state.
-- Jonathan
(Tapped on a touch device)
On Mon, 18 Jan 2021, 12:29 am Frederic Thevenet,
mailto:thevenet.f...@free.fr>> wrote:
Hi,
From the perspective of the application developer, I think
throwing a
runtime exception if the key does not exists on a given platform is
potentially risky, as the API provided no hints that a given key
might
not exists an other platforms, and this oversight will only manifest
itself at runtime, on said platform.
With the other two proposed solution (three-state return and Checked
exception) the API itself reminds its would be consumer that they
should
consider a case where the operation is invalid.
I'm personally not keen on checked exceptions in such a scenario
either,
as it would require an extra API to check for the existence of a
given
key on the current platform, or condemn developers to implement
conditional logic via exception catching (or require developer to
know
what specific keys exists on what platform before-hand to do the
check).
Given all that, my personal preference would go to a three state
return
solution.
On that topic, is there anything that would preclude the use of an
Optional to represent these three states, if we want to
avoid
introducing new enums? It seems to me its semantics aligns quite
nicely
with the problem at hand.
Fred
On 16/01/2021 17:41, Kevin Rushforth wrote:
> 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
>> mailto:kevin.rushfo...@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,
>>
Re: New API to read Caps-Lock and Num-Lock state
Looking at the use case for this request, which is to warn the user while
typing in password fields, I tried to write some simple code for it using
the Optional approach:
Optional result = Platform.isKeyLocked(KeyCode.CAPS+LOCK);
result.ifPresentOrElse(on -> label.setText("Caps Lock is " + (on ?
"on" : "off")),
() -> label.setText("Check Caps Lock"));
In practical terms, a key event listener would need to be added to the
password field to react to Caps Lock presses, and that will call the code
above.
I think that this is the best option.
On Sun, Jan 17, 2021 at 8:10 PM Frederic Thevenet
wrote:
> I realize that my suggestion was somewhat unclear, apology about that.
>
> I wasn't suggesting that we return null to count as the third state, but
> indeed that we leverage the isPresent state of the optional, alongside
> with the two states provided by the Boolean, e.g:
>
> isKeyLocked(KeyCode.NUM_LOCK).ifPresent(locked-> {
> // The num_lock key exists on the current platform
> if (locked){
> // React to the key being locked
> } else {
> // Or to the key not being locked
> });
>
>
> On 17/01/2021 18:31, Jonathan Giles wrote:
> > A method returning Optional should never return null, as that undoes
> > the contract that Optional is supposed to represent, which is to avoid
> > NPEs by never being null itself, only empty in the absence of a
> > returned value. For this reason, an Optional should be considered two
> > state rather than three state.
> >
> > -- Jonathan
> > (Tapped on a touch device)
> >
> > On Mon, 18 Jan 2021, 12:29 am Frederic Thevenet,
> > mailto:thevenet.f...@free.fr>> wrote:
> >
> > Hi,
> >
> > From the perspective of the application developer, I think
> > throwing a
> > runtime exception if the key does not exists on a given platform is
> > potentially risky, as the API provided no hints that a given key
> > might
> > not exists an other platforms, and this oversight will only manifest
> > itself at runtime, on said platform.
> >
> > With the other two proposed solution (three-state return and Checked
> > exception) the API itself reminds its would be consumer that they
> > should
> > consider a case where the operation is invalid.
> >
> > I'm personally not keen on checked exceptions in such a scenario
> > either,
> > as it would require an extra API to check for the existence of a
> > given
> > key on the current platform, or condemn developers to implement
> > conditional logic via exception catching (or require developer to
> > know
> > what specific keys exists on what platform before-hand to do the
> > check).
> >
> > Given all that, my personal preference would go to a three state
> > return
> > solution.
> >
> > On that topic, is there anything that would preclude the use of an
> > Optional to represent these three states, if we want to
> > avoid
> > introducing new enums? It seems to me its semantics aligns quite
> > nicely
> > with the problem at hand.
> >
> > Fred
> >
> >
> > On 16/01/2021 17:41, Kevin Rushforth wrote:
> > > 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
> > >> mailto:kevin.rushfo...@oracle.com>
> > > >> wrote:
> > >>
> > >> For JavaFX 17, I am planning to add a minor enhancement to
> > read the
> > >> state of the keyboard lock keys, specifically,
Re: New API to read Caps-Lock and Num-Lock state
Ah, got it! That teach me to reply before 7am and before the coffee hits!
This might be a reasonable approach in that case. Certainly it does away
with the need for the enum and the exception.
-- Jonathan
(Tapped on a touch device)
On Mon, 18 Jan 2021, 6:59 am Nir Lisker, wrote:
> I think Frederic meant that the Optional is empty in the case where you
> can't reliably get the state of the key, otherwise the true and false
> values are for the on and off states. The Optional itself is never null.
>
> On Sun, Jan 17, 2021 at 7:31 PM Jonathan Giles
> wrote:
>
>> A method returning Optional should never return null, as that undoes the
>> contract that Optional is supposed to represent, which is to avoid NPEs by
>> never being null itself, only empty in the absence of a returned value.
>> For
>> this reason, an Optional should be considered two state rather than three
>> state.
>>
>> -- Jonathan
>> (Tapped on a touch device)
>>
>> On Mon, 18 Jan 2021, 12:29 am Frederic Thevenet,
>> wrote:
>>
>> > Hi,
>> >
>> > From the perspective of the application developer, I think throwing a
>> > runtime exception if the key does not exists on a given platform is
>> > potentially risky, as the API provided no hints that a given key might
>> > not exists an other platforms, and this oversight will only manifest
>> > itself at runtime, on said platform.
>> >
>> > With the other two proposed solution (three-state return and Checked
>> > exception) the API itself reminds its would be consumer that they should
>> > consider a case where the operation is invalid.
>> >
>> > I'm personally not keen on checked exceptions in such a scenario either,
>> > as it would require an extra API to check for the existence of a given
>> > key on the current platform, or condemn developers to implement
>> > conditional logic via exception catching (or require developer to know
>> > what specific keys exists on what platform before-hand to do the check).
>> >
>> > Given all that, my personal preference would go to a three state return
>> > solution.
>> >
>> > On that topic, is there anything that would preclude the use of an
>> > Optional to represent these three states, if we want to avoid
>> > introducing new enums? It seems to me its semantics aligns quite nicely
>> > with the problem at hand.
>> >
>> > Fred
>> >
>> >
>> > On 16/01/2021 17:41, Kevin Rushforth wrote:
>> > > 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
>> > >> mailto:kevin.rushfo...@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]
Re: New API to read Caps-Lock and Num-Lock state
I realize that my suggestion was somewhat unclear, apology about that.
I wasn't suggesting that we return null to count as the third state, but
indeed that we leverage the isPresent state of the optional, alongside
with the two states provided by the Boolean, e.g:
isKeyLocked(KeyCode.NUM_LOCK).ifPresent(locked-> {
// The num_lock key exists on the current platform
if (locked){
// React to the key being locked
} else {
// Or to the key not being locked
});
On 17/01/2021 18:31, Jonathan Giles wrote:
A method returning Optional should never return null, as that undoes
the contract that Optional is supposed to represent, which is to avoid
NPEs by never being null itself, only empty in the absence of a
returned value. For this reason, an Optional should be considered two
state rather than three state.
-- Jonathan
(Tapped on a touch device)
On Mon, 18 Jan 2021, 12:29 am Frederic Thevenet,
mailto:thevenet.f...@free.fr>> wrote:
Hi,
From the perspective of the application developer, I think
throwing a
runtime exception if the key does not exists on a given platform is
potentially risky, as the API provided no hints that a given key
might
not exists an other platforms, and this oversight will only manifest
itself at runtime, on said platform.
With the other two proposed solution (three-state return and Checked
exception) the API itself reminds its would be consumer that they
should
consider a case where the operation is invalid.
I'm personally not keen on checked exceptions in such a scenario
either,
as it would require an extra API to check for the existence of a
given
key on the current platform, or condemn developers to implement
conditional logic via exception catching (or require developer to
know
what specific keys exists on what platform before-hand to do the
check).
Given all that, my personal preference would go to a three state
return
solution.
On that topic, is there anything that would preclude the use of an
Optional to represent these three states, if we want to
avoid
introducing new enums? It seems to me its semantics aligns quite
nicely
with the problem at hand.
Fred
On 16/01/2021 17:41, Kevin Rushforth wrote:
> 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
>> mailto:kevin.rushfo...@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]
Re: New API to read Caps-Lock and Num-Lock state
I think Frederic meant that the Optional is empty in the case where you
can't reliably get the state of the key, otherwise the true and false
values are for the on and off states. The Optional itself is never null.
On Sun, Jan 17, 2021 at 7:31 PM Jonathan Giles
wrote:
> A method returning Optional should never return null, as that undoes the
> contract that Optional is supposed to represent, which is to avoid NPEs by
> never being null itself, only empty in the absence of a returned value. For
> this reason, an Optional should be considered two state rather than three
> state.
>
> -- Jonathan
> (Tapped on a touch device)
>
> On Mon, 18 Jan 2021, 12:29 am Frederic Thevenet,
> wrote:
>
> > Hi,
> >
> > From the perspective of the application developer, I think throwing a
> > runtime exception if the key does not exists on a given platform is
> > potentially risky, as the API provided no hints that a given key might
> > not exists an other platforms, and this oversight will only manifest
> > itself at runtime, on said platform.
> >
> > With the other two proposed solution (three-state return and Checked
> > exception) the API itself reminds its would be consumer that they should
> > consider a case where the operation is invalid.
> >
> > I'm personally not keen on checked exceptions in such a scenario either,
> > as it would require an extra API to check for the existence of a given
> > key on the current platform, or condemn developers to implement
> > conditional logic via exception catching (or require developer to know
> > what specific keys exists on what platform before-hand to do the check).
> >
> > Given all that, my personal preference would go to a three state return
> > solution.
> >
> > On that topic, is there anything that would preclude the use of an
> > Optional to represent these three states, if we want to avoid
> > introducing new enums? It seems to me its semantics aligns quite nicely
> > with the problem at hand.
> >
> > Fred
> >
> >
> > On 16/01/2021 17:41, Kevin Rushforth wrote:
> > > 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
> > >> mailto:kevin.rushfo...@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
> > >>
> > >>
> > >
> >
>
Re: New API to read Caps-Lock and Num-Lock state
A method returning Optional should never return null, as that undoes the
contract that Optional is supposed to represent, which is to avoid NPEs by
never being null itself, only empty in the absence of a returned value. For
this reason, an Optional should be considered two state rather than three
state.
-- Jonathan
(Tapped on a touch device)
On Mon, 18 Jan 2021, 12:29 am Frederic Thevenet,
wrote:
> Hi,
>
> From the perspective of the application developer, I think throwing a
> runtime exception if the key does not exists on a given platform is
> potentially risky, as the API provided no hints that a given key might
> not exists an other platforms, and this oversight will only manifest
> itself at runtime, on said platform.
>
> With the other two proposed solution (three-state return and Checked
> exception) the API itself reminds its would be consumer that they should
> consider a case where the operation is invalid.
>
> I'm personally not keen on checked exceptions in such a scenario either,
> as it would require an extra API to check for the existence of a given
> key on the current platform, or condemn developers to implement
> conditional logic via exception catching (or require developer to know
> what specific keys exists on what platform before-hand to do the check).
>
> Given all that, my personal preference would go to a three state return
> solution.
>
> On that topic, is there anything that would preclude the use of an
> Optional to represent these three states, if we want to avoid
> introducing new enums? It seems to me its semantics aligns quite nicely
> with the problem at hand.
>
> Fred
>
>
> On 16/01/2021 17:41, Kevin Rushforth wrote:
> > 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
> >> mailto:kevin.rushfo...@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
> >>
> >>
> >
>
Re: New API to read Caps-Lock and Num-Lock state
Hi,
From the perspective of the application developer, I think throwing a
runtime exception if the key does not exists on a given platform is
potentially risky, as the API provided no hints that a given key might
not exists an other platforms, and this oversight will only manifest
itself at runtime, on said platform.
With the other two proposed solution (three-state return and Checked
exception) the API itself reminds its would be consumer that they should
consider a case where the operation is invalid.
I'm personally not keen on checked exceptions in such a scenario either,
as it would require an extra API to check for the existence of a given
key on the current platform, or condemn developers to implement
conditional logic via exception catching (or require developer to know
what specific keys exists on what platform before-hand to do the check).
Given all that, my personal preference would go to a three state return
solution.
On that topic, is there anything that would preclude the use of an
Optional to represent these three states, if we want to avoid
introducing new enums? It seems to me its semantics aligns quite nicely
with the problem at hand.
Fred
On 16/01/2021 17:41, Kevin Rushforth wrote:
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
mailto:kevin.rushfo...@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
Re: New API to read Caps-Lock and Num-Lock state
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
mailto:kevin.rushfo...@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
Re: New API to read Caps-Lock and Num-Lock state
Let's separate out the questions of what to do if we can't reliably get
the state of a key on a particular platform versus what to do if the key
isn't present (on a system where we could get the state if it were there).
The latter case seems clear: returning false is the right answer, since
it is an accurate representation of the state. This is somewhat similar
to reporting the state of the 5th button on a 3-button mouse (it's not a
perfect analogy, since we're talking about sticky state here, not
transient state that is part of the event in question, but close enough).
The former case is the more interesting one, since we could report
inaccurate information, so simply returning false seems wrong. I think
we have three choices: 1) throw an exception; 2) provide a separate
query method; or 3) return a three-value enum rather than a boolean
(e.g., OFF, ON, UNKNOWN). My current thinking is to throw a exception,
but I'd like to hear other opinions as well.
One other question is whether we should include SCROLL_LOCK along with
CAPS_LOCK and NUM_LOCK. I included it below, but I'm leaning towards
removing it, since it is not a common key state these days (and it isn't
clear what an app would do with the information).
Here is the currently proposed javadoc for comment:
/**
* Returns a flag indicating whether the key corresponding to
{@code keyCode}
* is in the locked or "on" state.
* {@code keyCode} must be one of: {@link KeyCode#CAPS},
* {@link KeyCode#NUM_LOCK}, or {@link KeyCode#SCROLL_LOCK}.
* If the underlying system is not able to determine the state of the
* specified {@code keyCode}, an UnsupportedOperationException is
thrown.
* If the keyboard attached to the system doesn't have the
specified key,
* {@code false} is returned.
* This method must be called on the JavaFX Application thread.
*
* @param keyCode the KeyCode of the lock state to query
*
* @throws IllegalArgumentException if {@code keyCode} is not one
of the
* valid KeyCode values.
*
* @throws UnsupportedOperationException if the underlying system
is not
* able to determine the state of the specified {@code keyCode}
*
* @throws IllegalStateException if this method is called on a thread
* other than the JavaFX Application Thread.
*
* @return {@code true} if the key corresponding to {@code keyCode}
* is in the locked or "on" state; {@code false} otherwise
*
* @since 17
*/
public static boolean isKeyLocked(KeyCode keyCode);
-- Kevin
On 1/15/2021 8:34 PM, Nir Lisker wrote:
What do the methods that check if a mouse button is pressed, but the
button does not exist on the mouse, do?
Maybe it's a hint for consistency.
On Sat, Jan 16, 2021 at 5:09 AM Dan Howard > wrote:
Please no additional exceptions. It only makes me think in a platform
specific way. Better would be an extra method that can I can check if
key exists. But if the key exists or is not pressed it should simply
return false. IMO
On 1/15/2021 12:39 PM, Kevin Rushforth 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
>
Re: New API to read Caps-Lock and Num-Lock state
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
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
>
>
Re: New API to read Caps-Lock and Num-Lock state
What do the methods that check if a mouse button is pressed, but the button does not exist on the mouse, do? Maybe it's a hint for consistency. On Sat, Jan 16, 2021 at 5:09 AM Dan Howard wrote: > Please no additional exceptions. It only makes me think in a platform > specific way. Better would be an extra method that can I can check if > key exists. But if the key exists or is not pressed it should simply > return false. IMO > > On 1/15/2021 12:39 PM, Kevin Rushforth 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 > > >
Re: New API to read Caps-Lock and Num-Lock state
Please no additional exceptions. It only makes me think in a platform specific way. Better would be an extra method that can I can check if key exists. But if the key exists or is not pressed it should simply return false. IMO On 1/15/2021 12:39 PM, Kevin Rushforth 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
