Dear Michael:
I don’t understand. In the past month and a half, we identified a number of
problems, and are converging at a solution. Do you want to restart the
process? Is there a special order of doing things you would rather see?
-andy
From: openjfx-dev <openjfx-dev-r...@openjdk.org> on behalf of Michael Strauß
<michaelstr...@gmail.com>
Date: Monday, November 20, 2023 at 14:06
To:
Cc: openjfx-dev@openjdk.org <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 Behavior
API. We should decide whether we want to revamp the control
architecture at all, and if we do, then we should do the large-scale
engineering first. Any control architecture proposal that has been put
forth so far will not survive the rigorous follow-up engineering
effort unscathed. Doing that first will undoubtedly inform the
specifics of a potential InputMap API. If this was a minor feature, we
could do it right now. But compared to other recent feature additions,
this one has a very large surface.
In an earlier email, you commented that maybe there wasn't enough
engineering capacity at hand to do big things. But I think the
discussions and preliminary work around Controls and Behaviors show
that people are, in fact, willing and committed to investing a lot of
effort to contribute to this project. So I would advocate to start by
thinking big, and seeing where we end up.
On Mon, Nov 20, 2023 at 9:16 PM Andy Goryachev
<andy.goryac...@oracle.com> wrote:
>
> 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 Input Map (more details later).
>
>
>
> Control gets an InputMap property which stores the user event handlers and
> the user key bindings.
>
>
>
> Skin has a SkinInputMap, a similar construct, which stores the event handlers
> and the key bindings registered by the behavior. The SkinInputMap comes in
> two flavors: one for the stateless behavior use case, and one for stateful
> behavior use case. In either case the skin input map is set via
> Skin.setSkinInputMap() (a placeholder name, can be changed).
>
>
>
> The difference between the two is the signature of the “function” mapped to a
> FunctionTag: the stateless requires Consumer<C extends Control>, and a
> stateful accepts a simple Runnable.
>
>
>
> Furthermore, the event handling priority can be encapsulated within the input
> maps. For example, any event handler registered via either InputMap or
> SkinInputMap is guaranteed to be called according to its priority. For
> example, we could have five levels (listed in the order of precedence):
>
>
>
> USER_HIGH
>
> SKIN_HIGH
>
> USER_MID
>
> SKIN_LOW
>
> USER_LOW
>
>
>
> Basically, event handlers added to the control’s InputMap can have {
> USER_HIGH, USER_MID, USER_LOW } priority, and those added to SkinInputMap can
> have { SKIN_HIGH, SKIN_LOW }. This makes it unnecessary to change the
> existing event handling APIs but solves the issue with undetermined order of
> event handlers execution that we currently have in Controls.
>
>
>
>
>
> Comment:
>
> SkinInputMap is basically an equivalent of BehaviorContext in John’s
> proposal, and priority levels are unambiguous extension of Michael’s
> EventHandlerPriority.
>
>
>
> What do you think?
>
>
>
> -andy
