[External] : Re: Proof of concept pull request for Behavior API (PR 1265)

[John Hendrikx]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20231024/b1085f84/attachment.htm>