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 these
problems making them harder to address in the future.
I'll reiterate what I think are more fundamental issues that should be
addressed:
1. Behaviors/Skins/Controls should not be hijacking events for their own
purposes before the user has their say in their handling. If the user is
not consuming the event (at any level), only then should it fall back to
defaults. The reason why it currently works this way is because the
public infrastructure for event handling is being used by Skin and
Behavior implementations; this infrastructure however by its nature is a
first come first serve system (unlike listeners), which makes it risky
to share with users unless measures are taken to ensure there are no
visible side effects of this sharing. Effectively this also means Skins
and Behaviors can *never* add a new event handler, or even a key mapping
without risking breaking existing apps. Even consuming a new event in an
existing handler, or changing its consumption pattern can cause breakage
as it currently stands.
2. Separation of Behaviors and Skins. Even for complex controls this is
possible, if there is a willingness to do so. This will open up far
easier extension of the FX platform where the choice is not to either
throw away all behavior and implement everything yourself, or hope you
can sufficiently hack the existing skin (which were never designed for
extension) to suit your needs.
3. Provide rock solid control primitives, and provide the infrastructure
to build more complicated controls. I should be able to copy/paste any
FX control, give it a new name, and then have it behave exactly as the
original in all respects. This may mean opening up (or more likely,
evaluating and partially redesigning) certain private API's (like focus
traversal).
I feel strongly that these would provide far more value currently, and,
as these are all aspects that can't be addressed easily by 3rd parties
or be worked around, only FX developers can solve these.
As far as the proposal is concerned, I feel that it is taking a giant
leap towards a perceived solution for an X/Y type problem. I think we
should be making far smaller incremental changes and fixes, and seeing
what those bring. This may eventually lead to an InputMap type system,
but it could also lead to a place where the issue to provide it has
become less urgent, giving us time to address other more fundamental
problems.
--John
On 07/05/2024 10:44, Michael Strauß wrote:
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
overly specific in trying to solve problems for which general-purpose
APIs like event handlers can be extended to work just as well (and
open up many more use cases than just those of a bespoke control API).
The fact that the API tries to fix a problem with the event system
itself (unpredictable invocation order) is a red flag. We should fix
this problem where it originates, which is the event API; crafting
workaround APIs in other parts of JavaFX doesn't seem to be the right
approach to me. This would also help to break the problem down into
more manageable chunks: improve the event system first, then see how
that influences the remaining problems that need to be solved.
You provide several examples of what the InputMap API can do:
1. Adding a new key mapping
// creates a new key binding mapped to an external function
control.getInputMap().registerKey(KeyBinding.shortcut(KeyCode.W), () -> {
externalFunction();
});
I don't see why this is needed. It doesn't seem to be easier than
using a plain old event handler, it's just different.
2. Redefine an existing function
// redefine function keeping existing key mappings
getInputMap().registerFunction(Tag.COPY, (control) -> customCopy());
If I want to change the meaning of the copy() method, can I not just
override the method and provide my own implementation? Plain old Java
seems to do the job.
3. Map an existing function to a new binding
// map a new key binding
control.getInputMap().registerKey(KeyBinding.shortcut(KeyCode.W),
Tag.COPY);
Again, an event handler would do the job here.
4. Obtain the default function
// obtains the default function handler
FunctionHandler<?> h = getInputMap().getDefaultFunction(Tag.COPY);
If I override the copy() method to provide my own implementation, I
could also add a defaultCopy() method that calls the base
implementation. Then I can call both copy() and defaultCopy().
(I don't know why I would want to do this, though.)
To summarize: the way I see it, your examples don't provide a
compelling reason why we need this new API. Given the size and
complexity of the proposal, I suggest to break the problem down into
more manageable parts, and solve the most fundamental issues first. At
the very least, the issue with event invocation ordering should be
solved in the event system.
On Mon, Mar 11, 2024 at 4:22 PM Andy Goryachev
<andy.goryac...@oracle.com> wrote:
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 some static behavior to avoid the per-instance penalty
clearer separation of concerns between controls, skins, and behaviors
desire to have some sort of public API for behaviors
need for addressing an issue with the event handler execution order between
application and skins
I would like to restart the discussion by submitting the updated proposal [0]
which addresses the issues raised earlier. The new proposal retains the idea
of allowing wider customization of key mappings via the InputMap. The new
features include:
separation of SkinInputMap from the control's InputMap
enabling static skin input maps for stateless behaviors
explicit priority levels for event handlers and key mappings created by the
application and by the skin
The ideas put forth in this proposal have been validated with the
proof-of-concept migration of some non-trivial controls:
complex popup-like controls: ComboBox, ColorPicker, DatePicker
complex text input controls: PasswordField, TextArea, TextField
control with a stateless behavior: TabPane
as well as a brand new RichTextArea control being incubated [8].
Please take a look at the proposal [0], a list of discussion points [1], and
the API Specification (javadoc) [2]. While the proposed API is ready for
review, it isn't complete nor set in stone. We are looking for feedback, and
will update the proposal based on the suggestions we receive from the
community. We encourage you to comment either in the mailing list, or by
leaving comments inline in a draft pull request [3].
For context, the links to the original RFE [4] and the earlier proposals [6],
[7] are provided below.
What do you think?
-andy
References
[0] Proposal:
https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2.md
[1] Discussion points:
https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV2-Discussion.md
[2] API specification (javadoc):
https://cr.openjdk.org/~angorya/InputMapV2/javadoc/
[3] Draft Pull Request for API comments and feedback:
https://github.com/openjdk/jfx/pull/1395
[4] Public InputMap RFE: https://bugs.openjdk.org/browse/JDK-8314968
[5] Documenting behaviors (WIP):
https://github.com/openjdk/jfx/tree/master/doc-files/behavior
[6] Earlier proposal:
https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/BehaviorInputMapProposal.md
[7] Earlier proposal in the OpenJFX mailing list:
https://mail.openjdk.org/pipermail/openjfx-dev/2023-September/042819.html
[8] RichTextArea (Incubator)
https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md
