17:15
To: openjfx-dev@openjdk.org
Subject: Re: Public Behavior API proposal
I don't want to restart the process, but I suspect that InputMap might
be better suited for specific controls only, not as a general-purpose
API. Maybe InputMap is part of a specific type of Behavior? Do you
think
I don't want to restart the process, but I suspect that InputMap might
be better suited for specific controls only, not as a general-purpose
API. Maybe InputMap is part of a specific type of Behavior? Do you
think that InputMap can carry its own weight, independent of a future
extension of the cont
Date: Monday, November 20, 2023 at 14:06
To:
Cc: openjfx-dev@openjdk.org
Subject: Re: Public Behavior API proposal
Hi Andy!
I think this can be a valid approch, but I have concerns regarding the
order in which we do things here.
In my opinion, InputMap is a special case of a more general
Hi Andy!
I think this can be a valid approch, but I have concerns regarding the
order in which we do things here.
In my opinion, InputMap is a special case of a more general Behavior
API. We should decide whether we want to revamp the control
architecture at all, and if we do, then we should do t
Dear colleagues:
I wanted to gauge your opinion on a slightly different approach that addresses
both John’s stateless behaviors use case as well as make it unnecessary to
change existing event handling APIs but still enforce the right order of event
handler execution.
Let’s call it a Split Inp
On 13/11/2023 07:14, Michael Strauß wrote:
Hi John,
I think this is an excellent summary of all the discussions so far,
and the best proposal I've seen for a comprehensive control
architecture capable of addressing many shortcomings of the existing
controls.
Here are some thoughts:
1. Semant
Hi Andy,
I don't think these really qualify as a good enough reason to expose an
InputMap API by themselves.
The first comment sounds like an X/Y problem, where the user wants to
achieve X (remove unwanted behavior) and thinks Y (exposing InputMap) is
the solution -- certainly that is curren
Dear colleagues:
I wanted to share some of the feedback we received which might be relevant to
the input map / behavior discussion (and sorry for not sending it earlier).
Email addresses in DM are redacted (though some of the responses might be from
this mailing list anyway).
Robert REDACTE
behalf of John Hendrikx
Date: Sunday, November 12, 2023 at 16:13
To: openjfx-dev@openjdk.org , Michael Strauß
Subject: Re: Public Behavior API proposal
Hi everyone, and specifically Andy and Michael,
I'm working on updating the Behavior API proposal, and I've been
thinking about th
Hi John,
I think this is an excellent summary of all the discussions so far,
and the best proposal I've seen for a comprehensive control
architecture capable of addressing many shortcomings of the existing
controls.
Here are some thoughts:
1. Semantic events == Interaction API
Previously, skins
Hi everyone, and specifically Andy and Michael,
I'm working on updating the Behavior API proposal, and I've been
thinking about the semantic events a lot. I would really like to hear
what you think, and how it matches with your ideas.
Quick recap, Semantic Events are high level events (like
Hi Michael,
Thanks a lot for this early feedback.
I think in light of it I will rework the proposal(s) to include semantic
events right from the beginning.
More inline comments below.
--John
On 07/11/2023 08:09, Michael Strauß wrote:
Hi John,
I like that you clearly define the terms Contr
Hi John,
I like that you clearly define the terms Control, Skin and Behavior,
as well as their roles within the control architecture.
However, I don't see how your proposal scales to non-trivial controls,
and I agree with Andy that the Button example doesn't help (because a
Button lacks substruct
und.
Cheers,
-andy
From: Andy Goryachev
Date: Monday, November 6, 2023 at 11:32
To: John Hendrikx , openjfx-dev@openjdk.org
Subject: Re: Public Behavior API proposal
Dear John:
Thank you for providing these proposals!
Do I understand correctly that the idea of translating input events into
cont
Dear John:
Thank you for providing these proposals!
Do I understand correctly that the idea of translating input events into
control-specific events and bubbling them up is now gone?
In “Goals” -
* Allow changing the skin of a control without having to recreate behavior
As we discussed b
15 matches
Mail list logo
