Cc: Kevin Rushforth , openjfx-dev
Subject: Re: [External] : Re: [Request for Comments] Behavior / InputMap
Andy,
I should have been clearer on why I wrote this up. I think once you’ve
identified the minimum API surface that’s probably all you should implement.
More important to me is whether
Andy,
I should have been clearer on why I wrote this up. I think once you’ve
identified the minimum API surface that’s probably all you should implement.
More important to me is whether reducing the API to a bunch of function tags
and two API calls does everything that needs to be done. For exa
Dear Martin:
Thank you for the analysis! Let me address each point
1) Ensure the user gets events before the control does. That’s a topic for a
different thread.
Partially supported, given the current limitation of the FX event handling
mechanism. A user key binding registered via InputMap
pment work and contribution from the
> community (ghm, #1014 :-)
>
> To summarize, what exactly is wrong with the proposal, and why? Please be
> specific.
>
> Thank you!
> -andy
>
>
>
> From: openjfx-dev <mailto:openjfx-dev-r...@openjdk.org>> on behalf
From: openjfx-dev on behalf of Michael Strauß
Date: Tuesday, October 17, 2023 at 15:56
To:
Cc: openjfx-dev@openjdk.org
Subject: Re: [External] : Re: [Request for Comments] Behavior / InputMap
Hi Andy,
I mean this in the most respectful way possible, but my feeling is that most of
the argume
Goryachev , openjfx-dev@openjdk.org
Subject: Re: [External] : Re: [Request for Comments] Behavior / InputMap
Hi Andy,
On 17/10/2023 20:07, Andy Goryachev wrote:
Dear John:
It looks like we have different views on the subject, so perhaps we should
invite other people to weigh in.
I would be
Hi Andy,
I mean this in the most respectful way possible, but my feeling is that
most of the arguments presented in favor of this enhancement seem to be
driven by an existing implementation, and not a "first-principles" analysis.
I've seen many proposals on this mailing list shot down with exactl
Hi Andy,
On 17/10/2023 20:07, Andy Goryachev wrote:
Dear John:
It looks like we have different views on the subject, so perhaps we
should invite other people to weigh in.
I would be interested to hear from others on this subject as well.
I feel however that I may need to make a more forma
Thank you!
We probably should extract the skinning discussion into a separate thread.
-andy
From: Pedro Duque Vieira
Date: Tuesday, October 17, 2023 at 05:57
To: Andy Goryachev
Cc: openjfx-dev@openjdk.org
Subject: Re: [External] : Re: [Request for Comments] Behavior / InputMap
Yes Input
Yes Input Map would be a welcome addition.
--
Talking about the Skin discussion:
Right now, I think Skins do both the Controller and View part of a Control,
making it really difficult to replace, extend, etc a Control's Skin...
I would have to think much more about this but I could see some kind
you
-andy
*From: *Martin Fox
*Date: *Saturday, October 14, 2023 at 14:48
*To: *John Hendrikx
*Cc: *Andy Goryachev ,
openjfx-dev@openjdk.org
*Subject: *Re: [External] : Re: [Request for Comments] Behavior / InputMap
I’ve been digging around in the code to get some context on the
existing mach
From: Martin Fox
Date: Monday, October 16, 2023 at 14:20
To: Andy Goryachev
Cc: John Hendrikx , openjfx-dev@openjdk.org
Subject: Re: [External] : Re: [Request for Comments] Behavior / InputMap
Andy,
John Hendrikx has given specific instances where this is breaking down already.
The JavaDoc
14:48
> To: John Hendrikx
> Cc: Andy Goryachev , openjfx-dev@openjdk.org
>
> Subject: Re: [External] : Re: [Request for Comments] Behavior / InputMap
>
> I’ve been digging around in the code to get some context on the existing
> machinery for ordering event handler execution. I
: Andy Goryachev , openjfx-dev@openjdk.org
Subject: Re: [External] : Re: [Request for Comments] Behavior / InputMap
I’ve been digging around in the code to get some context on the existing
machinery for ordering event handler execution. I haven’t had time to write up
test cases so all of this is
Thank you for clarification!
I just want to mention that here we are straying into what looks like a
parallel discussion about skins (nothing wrong about it!).
just the Skin part. This would likely be a big effort but perhaps it could be
split into smaller tasks till the end goal is achieved.
I’ve been digging around in the code to get some context on the existing
machinery for ordering event handler execution. I haven’t had time to write up
test cases so all of this is based on reading the spec and the code.
The current problem is that all handlers for a given Node are thrown into t
I fully agree with you here, Martin.
-andy
From: Martin Fox
Date: Thursday, October 12, 2023 at 09:31
To: Andy Goryachev
Cc: John Hendrikx , openjfx-dev@openjdk.org
Subject: Re: [External] : Re: [Request for Comments] Behavior / InputMap
Andy,
Speaking of the platform nuances – this
Andy,
> Speaking of the platform nuances – this might be relevant to the ongoing
> platform API discussion. Right now FX picks up nothing from the preferences
> set by the user within the OS. You are right, macOS allows the user to
> change key modifiers (for example, switch control and comma
Martin:
Right, the user-specific mappings are simply not possible in the current
version of FX.
Speaking of the platform nuances – this might be relevant to the ongoing
platform API discussion. Right now FX picks up nothing from the preferences
set by the user within the OS. You are right, m
Dear John:
Thanks again for a detailed response!
I noticed a theme that perhaps we should discuss first. It looks like there is
a desire to have:
1. stateless, shared behavior
2. behavior separated from the skin
3. input map as a separate entity (or entity that can be used by any Nod
Michael:
Thank you for a very thoughtful analysis! These are very good questions; allow
me to clarify.
1. It seems that the behavior implementation is still hard-coded into
the skin implementation. For example, TextFieldSkin uses
TextFieldBehavior; it doesn't seem like I can have a TextFieldSki
21 matches
Mail list logo
