Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make canvas selectable / keyboard binding implicit #662

Merged
merged 3 commits into from
Nov 4, 2024

Conversation

nikku
Copy link
Member

@nikku nikku commented Aug 15, 2022

Proposed Changes

Keyboard is now implicitly bound and Canvas is a focusable element.

This builds foundations to support cross-browser/application copy and paste and more general keyboard related UX enhancements.

This change introduces a predictable editing experience, simplifies the keyboard and ensures worry free interoperability with multiple editors and inputs on the page.

Focusable Canvas (c75285b)

The Canvas is now a focusable component, that is recognized accordingly by the browser, with all benefits for UX and interaction. New APIs are provided to allow restoring focus to the canvas.

Components that pull focus from the Canvas during modeling must ensure to restore the focus (if intended), via Canvas#restoreFocus.

Implicit Keyboard binding (b0f9a75)

Keyboard is now implicitly bound to the canvas element (svg). It provides behavior closer to native browser experience.

Previous calls to keyboard.bind(someElement) or configuration via keyboard.bindTo log a descriptive descriptive error:

image


Closes #661

@bpmn-io-tasks bpmn-io-tasks bot added the needs review Review pending label Aug 15, 2022
@nikku
Copy link
Member Author

nikku commented Aug 16, 2022

This can be tried out via:

npx @bpmn-io/sr nikku/bpmn-js-native-copy-paste#keyboard-bind -c "npm run start"

What I did is to remove any input quirks but rely on canvas to be actually browser selected. As a side-effect though that means that we consistently need to select the canvas when modeling operations happen:

capture IH2DTf_optimized

I do not see a simple way to accomplish this (yet).


At this point we have two options:

  • 🅰️ ditch this approach and keep existing manual keybinding
  • 🅱️ invest into consistently + properly re-focus the canvas

🅱️ is a requirement for cross browser copy + paste to work reliably so I'd argue we need to pursue this route anyway.

@nikku

This comment was marked as off-topic.

@barmac
Copy link
Member

barmac commented Aug 16, 2022

On MacOS, the focus state is persisted once I hover the canvas even if switch tab afterwards and come back. Is this is supposed to work like this? I am not opinionated but it would be logical to me that focus fades away when I move mouse outside without clicking.

@barmac

This comment was marked as outdated.

@nikku

This comment was marked as outdated.

@barmac

This comment was marked as outdated.

@nikku

This comment was marked as outdated.

@barmac
Copy link
Member

barmac commented Aug 16, 2022

Indeed, it's an out of scope feature to be fixed 😆

@marstamm
Copy link
Contributor

When we implicitly bind to the canvas, does it imply that extensions that rely on the command stack need to catch and trigger undo/redo manually? I'm thinking about the Properties panel here, where the most common case was to bind the keyboard to a common container.

I tested it on Edge and it works as expected, no new issues found from my side

@nikku

This comment was marked as outdated.

@nikku

This comment was marked as outdated.

@barmac

This comment was marked as outdated.

@nikku nikku marked this pull request as draft August 17, 2022 13:11
@bpmn-io-tasks bpmn-io-tasks bot added in progress Currently worked on and removed needs review Review pending labels Aug 17, 2022
@nikku
Copy link
Member Author

nikku commented Aug 17, 2022

Found the following issues integration testing this against different libraries in our eco-system:

  • dmn-js-drd: no issues (works out of the box)
  • dmn-js-decision-table / literal expression editor: has it's own keyboard implementation ➡️ needs porting to similar bind behavior, i.e. either make the table selectable + bind to it.
  • form-js: re-uses diagram-js keyboard but has no canvas ➡️ need to improve the bind / unbind behavior proposed in this PR to get the actual diagram container. Two ideas:
    • expose diagram with container in form-js, too
    • pass the container on diagram.init for components to catch it and do stuff with it (i.e . register/unregister key bindings)

@pinussilvestrus
Copy link
Contributor

form-js: re-uses diagram-js keyboard but has no canvas ➡️ need to improve the bind / unbind behavior proposed in this PR to get the actual diagram container. Two ideas:

  • expose diagram with container in form-js, too
  • pass the container on diagram.init for components to catch it and do stuff with it (i.e . register/unregister key bindings)

Given we follow one of these approaches, would we also have to follow up with explicit keyboard bindings for the Forms Properties Panel?

I'm asking because we plan to make it independent from the editor (e.g. render it in an own container, as we do with the other properties panels, cf. bpmn-io/form-js#291).

@nikku
Copy link
Member Author

nikku commented Aug 17, 2022

[...] would we also have to follow up with explicit keyboard bindings for the Forms Properties Panel?

Absolutely. Taking it one step at a time here though. Blueprint for properties panel binding can be found here: bpmn-io/bpmn-js-properties-panel#739.

@nikku
Copy link
Member Author

nikku commented Aug 17, 2022

This is now available as a pre-release via [email protected] and [email protected].

nikku added a commit to bpmn-io/bpmn-js-properties-panel that referenced this pull request Aug 17, 2022
This prepares for bpmn-io/diagram-js#662,
but is built in a way that is backwards compatible.
nikku added a commit to bpmn-io/bpmn-js-properties-panel that referenced this pull request Aug 17, 2022
This prepares for bpmn-io/diagram-js#662,
but is built in a way that is backwards compatible.
The `Canvas` is now a focusable component, that is recognized
accordingly by the browser, with all benefits for UX and interaction.

Components that pull focus from the `Canvas` during modeling must
ensure to restore the focus (if intended), via `Canvas#restoreFocus`.

Related to #661
Keyboard is now implicitly bound to the canvas element (svg).

Legacy configuration via `keyboard.bindTo` config or by passing an element
to `Keyboard#bind()` results in a descriptive error to be raised.

BREAKING CHANGES:

* Keyboard is now implicitly bound to the (focusable) canvas parent.
  Prior usages result in human readable errors to be raised.
Copy link
Member Author

@nikku nikku left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved ✔️.

Great work on following up @jarekdanielak 🚀

@jarekdanielak jarekdanielak merged commit 31972d1 into develop Nov 4, 2024
9 of 10 checks passed
@bpmn-io-tasks bpmn-io-tasks bot removed the needs review Review pending label Nov 4, 2024
@jarekdanielak jarekdanielak deleted the keyboard-bind branch November 4, 2024 14:13
nikku pushed a commit to bpmn-io/dmn-js that referenced this pull request Nov 7, 2024
deps(drd): update to [email protected]

feat(drd): keyboard is now implicit

  Related to bpmn-io/diagram-js#662
nikku pushed a commit to bpmn-io/dmn-js that referenced this pull request Nov 7, 2024
deps(drd): update to [email protected]

feat(drd): keyboard is now implicit

  Related to bpmn-io/diagram-js#662
nikku added a commit to camunda/camunda-bpmn-js that referenced this pull request Nov 8, 2024
nikku added a commit to camunda/camunda-bpmn-js that referenced this pull request Nov 11, 2024
nikku pushed a commit to torge-hmn/diagram-js that referenced this pull request Nov 14, 2024
nikku pushed a commit to torge-hmn/diagram-js that referenced this pull request Nov 14, 2024
nikku pushed a commit that referenced this pull request Nov 15, 2024
barmac pushed a commit to bpmn-io/form-js that referenced this pull request Nov 15, 2024
Editor is now focussed automatically on hover.

chore: update to diagram-js@15

Related to bpmn-io/diagram-js#662
barmac pushed a commit to bpmn-io/form-js that referenced this pull request Nov 15, 2024
This updates the library to diagram-js@15 which ships breaking changes.

BREAKING CHANGES:

* Keyboard is now implicitly bound to the container element.
  Calls to `keyboard.bind` with `node` and `keyboard.bindTo`
  now result with a descriptive console error and have no effect.

Related to bpmn-io/diagram-js#662
vsgoulart added a commit to bpmn-io/form-js that referenced this pull request Nov 18, 2024
This updates the library to diagram-js@15 which ships breaking changes.

BREAKING CHANGES:

* Keyboard is now implicitly bound to the container element.
  Calls to `keyboard.bind` with `node` and `keyboard.bindTo`
  now result with a descriptive console error and have no effect.

Related to bpmn-io/diagram-js#662
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make keyboard binding implicit / remove ability to bind to any element
6 participants