JEP 253: UI control skins and input mapping discussion

Tomas Mikula tomas.mikula at
Wed Aug 19 18:49:17 UTC 2015

I provided my feedback on the input mapping API some 4 months ago here (be
warned, it is a *long* discussion)

I am very disappointed that this API is being pushed forward with all its
flaws. It is both overly complex (both conceptually and in terms of the
amount of new classes introduced) and at the same time does not cover
simple use cases well (or not at all). Note that all my feedback was
constructive - suggesting a viable alternative (referring to WellBehavedFX
as a proof of concept, which is field tested by its use in RichTextFX).

Most importantly, I was arguing that InputMap should be a (minimal)
interface, instead of a class (locking us to the particular
implementation). InputMap in the current proposal mixes together two
concerns that should better be separated: 1. the InputMap API required by
Control (turns out it is just one method); and 2. API for the user to
construct such objects.

Splitting these two concerns would allow alternative an implementation of
2., e.g. an implementation where all controls of the same type (e.g.
Button) share the same instance of InputMap, instead of it being recreated
for each instance of Button.

Another wart is the InputMap#lookupMapping(Object) method (emphasis on
*Object*). I think everyone now agrees that Map#get(Object) is a terrible
API (although it might have been necessary for backwards compatibility at
the time). Aside from the untyped Object thing, the idea that when I want
the control to ignore some specific input, I first need to look up all the
mappings that match it and remove them is not going to work (simply because
the same mapping that matches the input to be ignored can also match some
other input that should not be ignored). User code that is using lookup is
also not going to be forward compatible, because the default mappings
installed by the controls themselves may change in a newer JavaFX version,
thus the return value of lookupMapping can be different in different JavaFX

"Specificity" seems like an unnecessary "feature" to me that I can't see
anyone putting into a good use. I cannot predict the effect of adding a
mapping without knowing what mappings with what specificity are already in
the InputMap. As a consequence, when as a user of JavaFX controls I want to
add a mapping, I need to be aware of what mappings are already installed by
the control itself (or its skin). Even if I knew all that, it can change in
a future version of JavaFX, so my code is not going to be forward

I just picked a few things. I encourage anyone interested to read the above
mentioned long discussion (relevant part starts from 2015).


On Sun, Aug 9, 2015 at 9:58 PM, Jonathan Giles <jonathan.giles at>

> The plan is for this kind of detail to be included in the javadoc
> documentation.
> Thanks,
> -- Jonathan
> On 7/08/2015 10:36 p.m., Mike Hearn wrote:
>> I don't know much about skins and how they work, as I haven't implemented
>> custom controls. My only knowledge comes from rummaging around inside the
>> code to find some hacky way to get a particular effect, often via CSS.
>> I was hoping to read about the skins infrastructure, what it's for, how
>> it works etc in the jfx.s.c.skins package description but no such luck. Is
>> the plan for the JavaDocs to give a high level description of skinning, how
>> to implement it in your own code etc, or are there plans for other articles
>> to describe this?

More information about the openjfx-dev mailing list