> I guess that's just the way I made it work. Implementing this in
> Control is not something I've thought about a lot.
It was really my thought experiment to begin with. Not sure it’s even possible
to do this without involving Scene and Scene knows nothing about Controls.
Don’t give it anothe
> But on re-reading the PR I see that it’s the child of the delegating node
> that’s adding the dispatcher. Could you elaborate on why that is?
I guess that's just the way I made it work. Implementing this in
Control is not something I've thought about a lot.
> I should have asked a different q
> On Feb 6, 2025, at 11:52 PM, Michael Strauß wrote:
>
>> This PR uses an event dispatcher to provide a cleaner way of channeling
>> keyboard events to another node. I haven’t prototyped the code but I suspect
>> a Control could do this using the existing API without any changes to the
>> N
> This PR uses an event dispatcher to provide a cleaner way of channeling
> keyboard events to another node. I haven’t prototyped the code but I suspect
> a Control could do this using the existing API without any changes to the
> Node class.
> This PR also provides an API to query a node’s dele
hould drop everything and re-write the
> whole thing, but I do want to continue the conversation.
>
> -andy
>
>
>
>
>
> From: Martin Fox
> Date: Friday, December 13, 2024 at 08:03
> To: Andy Goryachev
> Cc: OpenJFX
> Subject: Re: [External] : R
everything and re-write the whole thing,
but I do want to continue the conversation.
-andy
From: Martin Fox
Date: Friday, December 13, 2024 at 08:03
To: Andy Goryachev
Cc: OpenJFX
Subject: Re: [External] : Re: Focus delegation API
Hi Andy,
I’m trying to understand the use case you’ve outlined
on behalf of Michael Strauß
> mailto:michaelstr...@gmail.com>>
> Date: Monday, December 9, 2024 at 18:17
> To:
> Cc: openjfx-dev
> Subject: Re: [External] : Re: Focus delegation API
>
> > Yep, this seems unnecessary and counterproductive to me. All we need is to
>
ms to
be less optimal and more complicated.
What do you think?
-andy
From: openjfx-dev on behalf of Michael Strauß
Date: Monday, December 9, 2024 at 18:17
To:
Cc: openjfx-dev
Subject: Re: [External] : Re: Focus delegation API
> Yep, this seems unnecessary and counterproductive to me.
On 12/9/2024 6:16 PM, Michael Strauß wrote:
Yep, this seems unnecessary and counterproductive to me. All we need is to
drop the target field from the event.
I can't image that we would ever do this, considering that events have
been there almost from the beginning. We'd break half of the J
> Yep, this seems unnecessary and counterproductive to me. All we need is to
> drop the target field from the event.
I can't image that we would ever do this, considering that events have
been there almost from the beginning. We'd break half of the JavaFX
world if we changed the API of events.
I
g up part. There is no need for Event.target because there is no
extraneous events being bubbled up, and both CB and TF can process the events
as they come in.
What do you think?
-andy
From: Michael Strauß
Date: Monday, December 9, 2024 at 14:59
To: Andy Goryachev
Cc: openjfx-dev
Subjec
Hi Andy, your example highlights the observable defect that I've been
trying to explain. Answers to your questions below.
On Mon, Dec 9, 2024 at 10:27 PM Andy Goryachev
wrote:
>
> OK, let's backtrack a bit.
>
> consider this example
> https://github.com/andy-goryachev-oracle/Test/blob/main/src/g
priority.
BTW, you never responded to my questions in
https://mail.openjdk.org/pipermail/openjfx-dev/2024-November/050655.html
Cheers,
-andy
From: Andy Goryachev
Date: Friday, December 6, 2024 at 11:16
To: Michael Strauß
Cc: openjfx-dev
Subject: Re: Focus delegation API
Returning to this d
> Consider the following scenario: a compound control such as ComboBox, which
> has an editable TextField control as a part of its skin. It might be
> expected that the ComboBox shows the focused border instead of its TextField
> even when the latter has the input focus.
>
> When the user press
On 06/12/2024 20:16, Andy Goryachev wrote:
>
> Returning to this discussion.
>
>
>
> Consider the following scenario: a compound control such as ComboBox,
> which has an editable TextField control as a part of its skin. It
> might be expected that the ComboBox shows the focused border instead
>
of Michael Strauß
Date: Wednesday, November 20, 2024 at 14:42
To:
Cc: openjfx-dev
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 t
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 t
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 no
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
Responding to Nir's questions in this thread.
> I'd like to understand the focus and event handling problem better. If I have
> a focused TextField, all key events go to it. If I have a Spinner, which is a
> TextField with 2 Buttons, it is focused as a single unit and consumes key
> events whet
Really liking this approach. Thank you for working on this!
I didn't have a comprehensive solution for handling external and
internal focus yet, and only tried solving the event delegation
problem. This solution not only solves that, but also in such a way
that 3rd parties can use the same s
21 matches
Mail list logo
