JEP 253: UI control skins and input mapping discussion

[Jonathan Giles]

Tomas,

As it stands there exists two approaches being proposed (my one and 
yours). The purpose of my job is to create new API that benefits the 
community - your disappointment that I'm doing that is itself 
disappointing to me! :-) I couldn't progress our discussion in 
JDK-8091189 any further without undertaking the task of porting all 
existing UI controls to use the new API, so that I could understand the 
implications of my proposed approach. This has now been done and I'm 
reporting back to the community my findings. I am not pushing my API 
forward any more than I am surfacing it for discussion.

As I said in JavaFX Jira (now JBS), it would be really beneficial to 
have clarity around how WellBehavedFX would be used in JavaFX - I seem 
to recall we both agreed there was significant API in WellBehavedFX that 
wouldn't (and shouldn't) be part of an InputMap proposal. Whilst I 
appreciate it is a lot to ask, I think there needs to be some effort put 
into creating essentially another sandbox of openjfx that introduces 
WellBehavedFX in the way you envisage. Porting a small number of UI 
controls to use this would make it far more clear to me, and others who 
are interested in this, what your vision is. Otherwise we end up with 
long philosophical discussions and not enough code (which removes any 
confusion).

-- Jonathan

On 20/08/2015 6:49 a.m., Tomas Mikula wrote:
> 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.giles at oracle.com <mailto:jonathan.giles at 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?
>
>
>