Andy,
This might be just a matter of style but IMHO the limitations of the current
design aren’t listed in the Summary. For example, I have to get down to the
description section before I see this requirement:
ensure that user-defined mappings overwrite default ones and survive a
skin change
There’s nothing indicating that this is currently not working (or why it’s not
working). But perhaps this is something I should already know since I do spend
most of my time down in the platform code.
> Perhaps you could start a new thread listing some (all?) examples? I don’t
> think we have any existing documentation of the key bindings, so here we go:
> https://github.com/andy-goryachev-oracle/jfx/tree/8314906.behavior.test/doc-files/behavior
That’s a long list with several platform-specific nuances. You’ll need to
re-implement a big chunk of them for the table and tree view controls. In your
proposal you give an example of a RichTextArea and it will also need to
re-implement all of these.
In macOS 10.14 Apple created the NSStandardKeyBindingResponding
<https://developer.apple.com/documentation/appkit/nsstandardkeybindingresponding?language=objc>
protocol to encapsulate some of the potential binding targets. It’s overkill
and doesn’t cover a bunch of common bindings like Shortcut+C for Copy. BTW,
there’s a way for power-users to alter these bindings but it relies on them
being global.
I’ll dig into the proposal a bit more but probably not before next week.
Martin
>
> From: openjfx-dev <[email protected]> on behalf of Martin Fox
> <[email protected]>
> Date: Wednesday, October 11, 2023 at 10:27
> To: John Hendrikx <[email protected]>
> Cc: [email protected] <[email protected]>
> Subject: Re: [Request for Comments] Behavior / InputMap
>
>
> On Oct 11, 2023, at 1:03 AM, John Hendrikx <[email protected]> wrote:
>
> After reading John's message I realize that the InputMap proposal doesn’t
> list the limitations of the current design. It seems to be addressing some of
> the sequencing issues John mentions but doesn’t state outright that it’s
> doing so or why. I would set aside the proposal and focus on writing a
> problem statement document first.
> A system to remap keys can then be left squarely in the realm of user space,
> and much nicer solutions can be build by users than whatever JavaFX will
> provide out of the box.
>
> Seconded. Whatever Eclipse is doing to implement their key binding interface
> is deep and complex and there’s no way JavaFX could craft a solution Eclipse
> would use. I think that will be true for most apps that allow user
> customizable key bindings. And I’m pretty sure that when the user customizes
> a key binding Eclipse is not tracking down all of the affected controls and
> updating their per-instance key binding maps. Those maps have to be
> centralized and shared in some manner.
> So in short, what I think this should be about is:
>
> - Ensure user event handlers have priority over behavior/inputmap added ones
> - Ensure all behavior actions are available as methods on controls
>
> I have another recommendation (which may be more of a feature request). There
> should be a centralized way of mapping common keys to actions to ensure a
> consistent vocabulary across the user interface. As an example, on many
> controls Shift + up arrow should map to something like
> “moveUpAndExtendTheSelection”. There are a lot of these standardized
> bindings, some of them are platform specific, and it’s a really tall order to
> expect all of the individual control classes to get this right.
>
> On macOS there are two primary means of mapping a key event to an action and
> both are global. This means most of these mappings happen outside the
> individual controls and that the mappings are consistent across controls.
> This also addresses part of what John mentioned above; to make this work
> controls have to make their actions visible through callable methods.
>
> Phrased as problem statement: currently individual control classes need to
> separately implement a large set of standardized keyboard bindings. This is a
> maintenance and testing issue.
> - Ensure that if a key is handled by the control, that it is ONLY consumed
> when it actually triggers an action (navigation keys get consumed regardless,
> even if no focus change results, that's wrong).
>
> As I recall this is an issue with the traversal engine which is a maybe a
> separate topic (?) Was a bug ever entered on this?
>
> Martin
>
> On 10/10/2023 19:54, Andy Goryachev wrote:
>
> Re-sending with a smaller image (256kb limit, really?).
>
> From: Andy Goryachev <[email protected]>
> <mailto:[email protected]>
> Date: Tuesday, October 10, 2023 at 10:49
> To: Michael Strauß <[email protected]> <mailto:[email protected]>
> Cc: [email protected] <mailto:[email protected]>
> <[email protected]> <mailto:[email protected]>
> Subject: Re: [Request for Comments] Behavior / InputMap
>
> Dear Michael:
>
> Here is a use case for (re-)mapping by the user at runtime:
>
> <image002.jpg>
>
> (key mappings UI in Eclipse).
>
> I can think of several other cases (mentioned in the proposal, I think) so I
> think we can put the concept of immutable or global InputMap to rest.
>
> Whether the InputMap contains the reference to its control or not is a minor
> implementation detail, I think.
>
> -andy
>
>
> From: openjfx-dev <[email protected]>
> <mailto:[email protected]> on behalf of Michael Strauß
> <[email protected]> <mailto:[email protected]>
> Date: Tuesday, October 10, 2023 at 10:36
> To:
> Cc: [email protected] <mailto:[email protected]>
> <[email protected]> <mailto:[email protected]>
> Subject: Re: [Request for Comments] Behavior / InputMap
>
> > Yes, one of the features the new design provides is ability to modify key
> > mappings by the user at runtime. So yes, not only it needs to be mutable,
> > but it also adds some APIs for exactly that.
> >
>
> I struggle to see a use case for this feature. I can imagine that
> there might be some use cases that call for customized input mappings,
> but why would this translate to a _mutable_ input map? That's quite a
> departure from the way other parts of JavaFX work.
>
> For example, skins are also immutable. If you want to have a different
> skin for a control, you don't somehow modify the existing skin
> instance; instead, you'd create a new skin class (or -- somehow --
> extend an existing skin class), and then install that new skin on your
> control.
>
> An input map shouldn't bind input events directly to instance methods
> of a particular control instance. It should define the mapping of
> events to methods symbolically:
>
> Instead of mapping Event => instance.method(), it should map Event =>
> Control::method. The input map could then be stateless and immutable,
> and can be set on any control instance. If you want to change the
> mappings, just set a different input map instance. There's no need
> that an input map would retain a reference to any particular control,
> since the control reference can be passed into the input map just as
> easily.
