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.mik...@gmail.com> wrote: > > > On Wed, Aug 19, 2015 at 8:15 PM, Jonathan Giles <jonathan.gi...@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 > >
