Dear John: Thank you for further development of this idea, especially defining the separation between Control, Skin, and Behavior.
Do I read correctly that semantic events are currently off the table? Or, at least, either an implementation detail or some future enhancement? I also have a few comments in regards to the strict rules e.g. “C. never modifies its own publicly writable properties” and the reasoning behind those, but that deserves a separate email. For now, I just want to note that BehaviorContext looks suspiciously like an InputMap (a skin/behavior InputMap), and the fact that you invent a State class indicates that, at least in this example, we are dealing with a stateful behavior. In other words, why not have a BehaviorBase? So the only case where we might have a stateless behavior and thus save a few bytes by using a singleton key map is where the control either has no state, or the state is fully encapsulated within control’s properties. I agree we should support those (rare?) cases should developers want it. What I am getting at here is that if we provide an InputMap and a SkinInputMap instead, then we can have the freedom to implement stateful and stateless behaviors as well as provide key mapping functionality as well as the prioritization of event handlers (if registered via the input maps). What do you think? -andy From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of John Hendrikx <john.hendr...@gmail.com> Date: Friday, November 24, 2023 at 18:21 To: openjfx-dev@openjdk.org <openjfx-dev@openjdk.org>, Michael Strauß <michaelstr...@gmail.com> Subject: Looing for feedback: Behavior API Proposal V2 Hi List, I've written down a new Behavior API proposal which has some interesting changes to even better separate behavior from skins. Skins currently already determine much of the behavior by only installing specific event handlers, or only calling behaviors in specific instances (they effectively are already doing some interpretation or filtering of events). This proposal aims to do away with all that, allowing behaviors to be in full control on what events they wish to listen to, even for events triggered on the skins children or substructure. An example is SpinnerSkin, which currently dictates without the behavior being able to intervene that ALL mouse buttons will trigger the spinner buttons (this is most likely a bug, but shows that skins have too much control here). The behavior once triggered lacks the necessary information to filter this to only the primary button as the event was already interpreted by the skin. This proposal changes this by letting all relevant substructure events bubble up to the control level, where the behavior is free to install any event listeners it wants to do anything it wants. All that is needed to make this work is a way for the behavior to know on which part of the substructure an event was triggered. This can be determined by examining the event target, and together with already public information about the skins substructure (available for CSS) this is enough to allow behaviors to respond to any possible event performed on a specific piece of substructure, and not just events sanctioned by the skin. This will make it possible for behaviors to be a really powerful API to radically alter how visuals react to mouse movements, keyboard events, drags, gestures, etc, without being limited by the skin designer's imagination. An example would be to have Spinners react to the scroll wheel, which currently is not possible without the skin's cooperation. This proposal leaves out the semantic event concept for now as something that can be added later. Since they're not needed anymore for skins to communicate with behaviors, they can wait a bit. The proposal also includes ways of dealing with Behaviors that require knowledge of the exact visual layout a skin provides (TextAreaBehavior) that I think is not an unsatisfactory solution. https://gist.github.com/hjohn/c7b1bf9d4a4770b1b3ae854b20fbaa94 Looking forward to hearing your feedback! --John
