To clarify, > some behaviors cannot be decoupled from the skin
Imagine a specific skin that has a Node that accepts a user input. A scroll bar, a button, or a region with a some function. Unless this element is proclaimed as must-have for any skin and codified via some new public API (MySkin.getSomeElement()), it is specific to that particular skin and that particular behavior. Another example is when we try to extend a core control by extending its default skin and adding some additional state, linked to, again, a new input element in the new skin. This additional state is unknown to the core behavior, so we can’t simply bolt it on the existing behavior - both skin and the behavior must be extended. The opposite example: when a custom skin *removes* some input element, which might break the existing behavior which relies on the existing of the removed element. Does it make sense? For people listening in: please do not hesitate to offer your opinion on the subject. We are trying to come up with a solution for *you*, so your feedback is extremely important. It might look like John and I are fighting, but we really are trying to find the common ground. Cheers, -andy From: Andy Goryachev <andy.goryac...@oracle.com> Date: Monday, November 6, 2023 at 11:32 To: John Hendrikx <john.hendr...@gmail.com>, openjfx-dev@openjdk.org <openjfx-dev@openjdk.org> Subject: Re: Public Behavior API proposal Dear John: Thank you for providing these proposals! Do I understand correctly that the idea of translating input events into control-specific events and bubbling them up is now gone? In “Goals” - * Allow changing the skin of a control without having to recreate behavior As we discussed before, some behaviors cannot be decoupled from the skin. This alone should disqualify the proposal from the start. Perhaps choosing a more complex control rather than a Button for a proof of concept would have been a better starting point? Right now I don’t know what to do - do you want me to repeat the same arguments and explanations? Please advise. Thank you -andy From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of John Hendrikx <john.hendr...@gmail.com> Date: Sunday, November 5, 2023 at 18:05 To: openjfx-dev@openjdk.org <openjfx-dev@openjdk.org> Subject: Public Behavior API proposal As promised, a public Behavior API proposal. Summary: Introduce a new Behavior interface that can be set on a control to replace its current behavior. The new behavior can be fully custom or composed (or later subclassed) from a default behavior. Some default behaviors will be provided as part of this proposal, but not all. See here: https://gist.github.com/hjohn/293f3b0ec98562547d49832a2ce56fe7 --John
