Improve selection of a pool

[ingorichtsmeier]

Is your feature request related to a problem? Please describe.

As a user I wan to model properties for elements that I click on the diagram. This works well and intuitive for tasks and connections, but does not work for container elements such as participants and sub-processes:

If I click into a pool only selects the Collaboration properties. But it is much more important to access the elements of the Participant (name, history cleanup, candidate starter, ...)

Describe the solution you'd like

• Clicking into a container element selects it
• Dragging a container element (outside the drag area) still does not drag it (but drags the canvas instead)

Describe alternatives you've considered

None.

Additional context

When I model my process diagram in a pool, I have to select the begin of the pool to access the properties of the process in the properties panel.

In larger diagrams, it makes it very tedious. Scroll to the beginning, ...

The selection of the Collaboration is much less important for a developer.

[nikku]

Verified with @ingorichtsmeier that this is a UX issue. Moving to backlog.

We should investigate if we're able to separate click to select (for containers) from drag start. This way we'd be able to support this without breaking the existing move interaction.

[barmac]

I am going to look into this this week.

[barmac]

I am sharing here my findings so far:

• For "frame" elements like Participant and Group, we use CSS property pointer-events to decide which parts of the shape are interactive.
• Because we use pointer-events: stroke for the body of both of the shapes, it is transparent to the browser regarding mouse/touch interaction.

Solution sketch:

• Use pointer-events: all for the frame shapes.
• Decide in the application layer whether and how to react on the interaction.
• Ideally, the hit boxes should allow either both dragging and click interactions or only the clicks.

[barmac]

Use pointer-events: all for the frame shapes.

After a while, I think this should apply to Participants and SubProcesses, but not to the Group. I should select the Group only when I click the frame because there is no "body" of this element.

[barmac]

These are the events supported in diagram-js InteractionEvents:

• element.click
• element.contextmenu
• element.dblclick
• element.hover
• element.mousedown
• element.mousemove
• element.mouseup
• element.out

As long as there is no dragging in progress, only these should be fired for the element's body:

• element.click
• element.contextmenu
• element.dblclick

However, the rest should be fired for an element below to allow moving the canvas. Also, we should reactivate the events for the element when dragging interaction is in progress (handled currently via CSS).

[barmac]

Another, more detailed solution sketch:

• Introduce djs-hit-click-only type which accepts all pointer events
• However, when this new type is activated, check the element type:
  • For click-like events, handle the event as with other hit boxes.
  • For other events, handle the event with target overwritten to the first non-djs-hit-click-only hit taken from document.elementsFromPoint.

This may degrade the performance, so let's be careful.

[barmac]

Alternative (limited) solution:
Instead of using document.elementsFromPoint, always fall back to the canvas. The rest is the same.

[barmac]

Another idea:
Have hit boxes which don't allow dragging. Build the functionality in the dragging module so that it can decide whether dragging should be activated for the hit box.

Edit: This should be rather implemented in the Move module.

[barmac]

Another idea: Have hit boxes which don't allow dragging. Build the functionality in the dragging module so that it can decide whether dragging should be activated for the hit box.

Edit: This should be rather implemented in the Move module.

I ended up implementing this solution but the new hit box type disables only the element movement feature. As a result, we don't mess with events or document.elementsFromPoint, but still achieve the desired selectable Participant/SubProcess/Lane.

[barmac]

This is fixed upstream via bpmn-io/bpmn-js#1646

[Skaiir]

Closed via bc8b748