on behalf of John Hendrikx
Date: Wednesday, May 15, 2024 at 14:34
To: openjfx-dev@openjdk.org
Subject: Re: Proposal: Public InputMap (v2)
I can only second this.
If anything, the proposal highlights several fundamental problems in
current JavaFX by how it is trying to work around them. The work around
I can only second this.
If anything, the proposal highlights several fundamental problems in
current JavaFX by how it is trying to work around them. The work around
works for one area (key events) but does not address similar problems
for other events. The work around will also further cement
event handler (I just think it is unnecessary, but I trust you
will provide a good example shortly).
Thank you
-andy
From: openjfx-dev on behalf of Michael Strauß
Date: Tuesday, May 7, 2024 at 01:44
To:
Cc: openjfx-dev@openjdk.org
Subject: Re: Proposal: Public InputMap (v2)
Hi Andy
Hi Andy!
The updated proposal seems to be a slight refinement of the original
proposal, and I think most of the points raised in the previous
discussion still stand.
As it is, I still think that this is an exceptionally large API
surface for what the feature can actually bring to the table. It's
: Re: Proposal: Public InputMap (v2)
I've had a look into the proposal and I like it a lot.
I've had numerous encounters with "little tweaks" to keyboard handling and/or
behaviour that I had to work around, all of which would (as far as I can tell)
have been avoidable, if this API were in
I've had a look into the proposal and I like it a lot.
I've had numerous encounters with "little tweaks" to keyboard handling
and/or behaviour that I had to work around, all of which would (as far
as I can tell) have been avoidable, if this API were in existence.
So while there is quite some
Dear JavaFX developers:
Thank you all for your feedback on my earlier Behavior/InputMap proposal [6],
[7]. There was some positive reaction to the idea of allowing for easy
customization of JavaFX controls behavior, as well as some push back. Some of
the objections were:
* desire for
