Public Behavior API proposal

[Andy Goryachev]

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-retn at openjdk.org> on behalf of Michael Strauß <michaelstrau2 at gmail.com>
Date: Monday, November 20, 2023 at 14:06
To:
Cc: openjfx-dev at openjdk.org <openjfx-dev at 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.goryachev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20231120/ef70fff3/attachment.htm>