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
