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
