> I don't see how these problems are at all related. I failed to explain it clearly then. I'll try to write up a more detailed explanation after Thanksgiving.
-andy From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of Michael Strauß <michaelstr...@gmail.com> Date: Wednesday, November 20, 2024 at 14:42 To: Cc: openjfx-dev <openjfx-dev@openjdk.org> Subject: Re: Focus delegation API I don't see how these problems are at all related. My proposal solves the focus delegation problem that is inherent with composite controls, which is not even addressed by the InputMap proposal. It also solves an artifact of the event system, namely that key events are delivered to the focused node, which cannot simultaneously be the Spinner and its TextField. The ugly hack to make this work is to duplicate the event entirely, so that if you'd observe Spinner and listen for key events, you will see duplicated key presses. This is also not solved in any meaningful way by InputMap. On Wed, Nov 13, 2024 at 8:33 PM Andy Goryachev <andy.goryac...@oracle.com> wrote: > > I feel this is going in a wrong direction: the root cause of the issues we > are observing, in my opinion, is that the top-level Control is fighting for > control with the inner control, and the inner control's behaves as if it is a > top-level control. > > What should happen instead is to provide a way for the top-level Control to > disable those aspects of the inner control behavior (event handlers, key > bindings) that are not needed anymore, and replace them with the new logic. > Continuing the Spinner example, it is ok for the TextField (Spinner.editor) > to receive events, but the handling of certain key combinations should be > disabled and instead bubbled up to the Spinner behavior. > > I propose to use the InputMap > https://github.com/andy-goryachev-oracle/Test/blob/main/doc/InputMap/InputMapV3.md > for this purpose. > > -andy
