Dear John: It is difficult to review the alternative proposal for a number of reasons. A prototype is a good start, but for any proposal to go forward we need a bit more work. Let me enumerate the steps that we expect:
1. Provide an overview of the proposal following a JEP outline: Summary Goals Non-Goals Motivation Description Alternatives Risks and Assumptions Dependencies 2. A draft PR that provides a proof of concept, using, in this case, a few complex controls like TextArea, TableView, ComboBox. 3. Address the question raised earlier, perhaps by providing code examples (pseudo code is acceptable, I think). More specifically, I’d like to know how the following concerns will be addressed by the new proposal: Q1. Changing an existing key binding from one key combination to another. Q2. Remapping an existing key binding to a different function. Q3. Unmapping an existing key binding. Q4. Adding a new key binding mapped to a new function. Q5. (Q1...Q4) scenarios, at run time. Q6. How the set behavior handles a change from the default skin to a custom skin with some visual elements that expects input removed, and some added. Q7. Once the key binding has been modified, is it possible to invoke the default functionality? Q8. How are the platform-specific key bindings created? Q9. How are the skin-specific (see Q6) handlers removed when changing the skins? Q10. When a key press happens, does it cause a linear search or a map lookup? Thank you -andy From: John Hendrikx <john.hendr...@gmail.com> Date: Tuesday, October 24, 2023 at 04:58 To: Andy Goryachev <andy.goryac...@oracle.com>, openjfx-dev@openjdk.org <openjfx-dev@openjdk.org> Subject: Re: [External] : Re: Proof of concept pull request for Behavior API (PR 1265) On 23/10/2023 23:57, Andy Goryachev wrote: You'd create a new class, `MyBehavior`, By “customizing” I also mean at run time. Creating new classes wouldn’t work. This would also work at runtime, as the class you create can be instantiated with parameters that control its key binding behavior. Even though the standard Behaviors should probably be singletons (so they can be reused and composed) or have public well documented constructors, a custom behavior created by the user has no such re-usability restrictions. coupling I don’t think it is our choice - it is up to the skin designed. If they add a node that needs to take input, or if the behavior is drastically different, it is almost impossible to create a common interface. So skin and behaviors are coupled, besides we have to design for the worst case (of a totally different skin). The division between S and B comes mostly from the division between V and C in MVC. From a distance, the user does not see it at all - all they see is a control. JavaFX is not doing MVC. In MVC, the 3 components are not entangled; Model refers View, Controller refers View and Model, View refers nothing; in JavaFX the View (Skin) creates the Controller (Behavior); the View especially normally can be created without any dependencies, and can be tested as such; with Skins being tightly coupled to both Behaviors and Controls, that doesn't even come close. For it to be MVC you'd need to: - Remove reference from Skin to Control - Do not let Skins create Behaviors - Instantation order should be, create a Skin first (with no Control reference), then create the Control (with Skin as parameter or setter), then create a Behavior (with Control as parameter, and one or more Views (Skins)) What JavaFX is exactly, I don't know. It doesn't follow MVC (even though it claims to) because in the current setup the Skin is both V and C; that's not MVC. At most it is MS (Model Skin), and so there is no reason to expose anything beyond the Skin then, as that would just be pretending to be something that it is not. This suggest another metric at judging the usefulness of a design - how easy it is to understand and perform 80% of most common tasks. Now that I explained how key remappings would work, I don't see how this would disqualify the alternative proposal. There are more interesting ideas at the end of the message I am replying to - fxml, css, global changes - these go far beyond the simple input map improvement. I did mention this already, but neither open source community, nor my employer might have the resources to make such drastic changes. I didn't mention FXML, but yes, I gave some other things to think about. As for how drastic any of those are, that remains to be seen. Certainly the global changes would not be that hard at all. The CSS proposal would need some research if there is some will to go there; it assumes that the information needed can be transported in a reasonable manner to the key binding system using the existing CSS infrastructure. So we have to be realistic, I think. We are travelling to a different planet in a small spaceship and we only have so much material and oxygen to play with. A simple improvement that helps 80% of use cases might be better than a major redesign (I still think the event proposal involves major redesign). I think that if that's the case that we'd better focus on making it possible for 3rd parties to deliver these features, and do the simplest thing that would allow them to do so. That would be prioritized event handlers (so a 3rd party can always intercept before the Skin/Behavior gets to it) + a flag to skip system event handlers (ala consumed) to allow bubbling up. On top of that any key remapping or behavior change system can be constructed already. --John
