JEP 253: UI control skins and input mapping discussion

[Tomas Mikula]

Hi all,

it seems that after dropping input mapping API from JEP 253, Jonathan has
for now retracted from further work on this API. I nevertheless compiled a
list of some use cases and presented how they can be solved using
WellBehavedFX. I would like to invite anyone to supply other use cases and
comment on the current use cases, the presented solutions and the proposed
API.

https://github.com/TomasMikula/InputMapAPI

Thanks,
Tomas

On Wed, Aug 19, 2015 at 9:09 PM, Tomas Mikula <tomas.mikula at gmail.com>
wrote:

>
>
> On Wed, Aug 19, 2015 at 8:15 PM, Jonathan Giles <jonathan.giles at oracle.com
> > wrote:
>
>> Tomas, I hope you'll agree that throughout our long discussion on JBS we
>> both improved our implementations based on our discussion. To say that I
>> haven't addressed your issues isn't fair - I worked with you to understand
>> your issues and I addressed many of them as my InputMap implementation and
>> API iterated. We have fundamentally different views on how to implement
>> this, so I can't bend over and completely change my approach to your
>> approach - or else we'd not be doing a proper job of exploring the domain.
>
>
> I never meant it to sound like you (or JavaFX) should adopt my approach. I
> was just pointing out some flaws with the proposal, and in an attempt to
> also be constructive, I was referring to WellBehavedFX as an evidence that
> they indeed can be resolved.
>
>
>> I'm not saying one approach is right and the other is wrong - I'm working
>> on my idea of how to approach this, and as I said, I invite you to do the
>> same. In regard to 'closing doors' - I don't think anything I've done up to
>> now has closed doors. I believe that WellBehavedFX will continue to be able
>> to work in the current approach I have implemented (it just hooks into
>> EventHandlers, right?) - it just won't make use of any of it!
>
>
> By the same argument, neither is JavaFX closing doors to anyone who wants
> to implement their own UI toolkit. They just won't make use of any of it!
> :D More seriously though, no, the two mechanisms cannot coexist well on the
> same control: they both hook into event handlers and 1) the order in which
> event handlers are invoked is undefined and 2) all applicable event
> handlers are invoked, regardless of whether some of them consumed the
> event. In fact, if there was enough control over event handlers, there
> would be little motivation for any of this input mapping stuff. Since there
> can only be one mechanism in place, it better cover 99.99% of use cases.
>
>
>> Nothing I'm creating is being forced down anyones throats - it is an
>> implementation and API that is optional. As it stands, the sandbox repo I'm
>> working in has all controls using it, but that doesn't mean controls such
>> as your rich text editor are forced to use it, and I imagine that they will
>> continue to work well with your WellBehavedFX API and implementation. Am I
>> misunderstanding what you're saying? -- Jonathan
>
>
> If my control uses WellBehavedFX, and in JDK 9 there will be the new
> InputMap API, users (especially new ones) will try to use that API to
> customize input mappings (because, well, that is the JavaFX way to do it,
> right?). Except the two can interact in unpredictable ways (see above). Now
> if you say that they should study the control and the ways how to interact
> with it, that argument does not extend to generic code, where the type of
> node is known to be only Control (or Node), not the concrete custom
> control. So custom control authors will be forced to switch to the new API.
> So again, it better cover 99.99% of use cases.
>
> Regards,
> Tomas
>
>