I provided my feedback on the input mapping API some 4 months ago here (be warned, it is a *long* discussion) https://bugs.openjdk.java.net/browse/JDK-8091189
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 versions. "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 compatible. I just picked a few things. I encourage anyone interested to read the above mentioned long discussion (relevant part starts from 2015). Regards, Tomas On Sun, Aug 9, 2015 at 9:58 PM, Jonathan Giles <jonathan.gi...@oracle.com> wrote: > 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? >> > >
