JEP 253: UI control skins and input mapping discussion

[Tomas Mikula]

Hi Jonathan,

On Wed, Aug 19, 2015 at 7:00 PM, Jonathan Giles <jonathan.giles at oracle.com>
wrote:

> 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! :-)
>

My disappointment comes from not addressing the issues I have raised.


> 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.
>

That was the "template" part, i.e. the part which enables you to share an
input map across all instances of the same control. I'm not saying this
should or shouldn't be part of proposal. I'm saying the proposal should not
close doors to such implementations (by third parties or in future JavaFX
versions).


> 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).
>

 I don't have the bandwidth to port JavaFX controls. However, we can write
down a list of use-cases and present user code for them side by side (e.g.
a document on GitHub, BitBucket, ... to which both of us and possibly other
people have write access). These can include all the cases that you
encountered while porting JavaFX controls. Metrics on the implementation
(like the API surface) will be easy to calculate (I can restructure
WellBehavedFX to put the non-essential stuff into a separate package).

Regards,
Tomas


>
>
> -- 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>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?
>>>
>>
>>
>
>