[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: JEP 253: UI control skins and input mapping discussion
From:       Tomas Mikula <tomas.mikula () gmail ! com>
Date:       2015-08-20 1:09:45
Message-ID: CA+THruq7hihnP2MHod2cMLQp29+90R6NudqRcsw=ZGGB=yuLFw () mail ! gmail ! com
[Download RAW message or body]

On Wed, Aug 19, 2015 at 8:15 PM, Jonathan Giles <jonathan.giles@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
[prev in list] [next in list] [prev in thread] [next in thread]