-
Notifications
You must be signed in to change notification settings - Fork 418
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
Conversation
This can be tried out via:
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: I do not see a simple way to accomplish this (yet). At this point we have two options:
|
This comment was marked as off-topic.
This comment was marked as off-topic.
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. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
Indeed, it's an out of scope feature to be fixed 😆 |
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 |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
Found the following issues integration testing this against different libraries in our eco-system:
|
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). |
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. |
This is now available as a pre-release via |
This prepares for bpmn-io/diagram-js#662, but is built in a way that is backwards compatible.
This prepares for bpmn-io/diagram-js#662, but is built in a way that is backwards compatible.
dd0bb29
to
29247c8
Compare
0a92be2
to
3dd2d14
Compare
12fc078
to
57a9fe1
Compare
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.
There was a problem hiding this 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 🚀
deps(drd): update to [email protected] feat(drd): keyboard is now implicit Related to bpmn-io/diagram-js#662
deps(drd): update to [email protected] feat(drd): keyboard is now implicit Related to bpmn-io/diagram-js#662
This is now implicit, cf. bpmn-io/diagram-js#662
This is now implicit, cf. bpmn-io/diagram-js#662
Editor is now focussed automatically on hover. chore: update to diagram-js@15 Related to bpmn-io/diagram-js#662
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
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
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), viaCanvas#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 viakeyboard.bindTo
log a descriptive descriptive error:Closes #661