Add append to contextPad

[smbea]

What should we do?

Add a "append anything" entry to the palette which provides a menu with all possible elements.

What it should look like:

To do:

• Add entry to context pad
• Add append menu entries provider

Why should we do it?

To support create anything, see #1627

[nikku]

If done properly this closes the following issues:

• Improve semantic ordering in replace / append menu for "implementation" #1621
• When I append event subprocess it is appended as an expanded subprocess #1860
• Simplify appending expanded sub-processes camunda/camunda-modeler#2004
• Boundary event can be placed on process via append anything #1731
• #52 breaks modeler when append anything is used with keyboard bpmn-js-connectors-extension#54

[smbea]

UX discussion outcome (2023-01-16):

Let's interpret "append anything" as "add anything", a tool that can basically replace the palette in a way that is always close to where you are modeling. It provides all elements you might need. We can see how users react to this and adapt if needed.

• We shall keep elements that can't be directly connected (like event sub processes and boundary events).
• For boundary events: make sure boundary events aren't transformed into intermediate events. onClick should also trigger create mode (same as onDragStart).
• An improvement that can be done later on is to automatically attach boundary events to the tasks.

[smbea]

Currently having some difficulty with triggering create mode on keyboard (same as bpmn-io/bpmn-js-connectors-extension#54). The dragging module is not prepared to receive a KeyboardEvent because it can't extract the cursor position from it, therefore not being able to calculate the initial dragging position.

I only got this far (needs an initial mouse movement to be able to display the hover element):

Screen.Recording.2023-01-16.at.16.37.43.mov

[barmac]

How about we fake the initial cursor position based on the button position? That could mimic the mouse interaction. Still, it looks good enough as we don't aim for keyboard-only modeling at the moment.

[smbea]

@barmac I tried to calculate the position based on the target but it wasn't working out too well. We also try to get this position again (here) after the menu has been closed to add the placeholder, so we would need to save this position and re-use it. I did some messing around with it but the positioning was always off.

[nikku]

We have a utility to record and provide the last mouse position Mouse#getLastMoveEvent.

I think it is fine to use that (and otherwise resort to "show only once mouse moved for the first time).

[nikku]

Also interesting if #1801 (comment) does not work: Why does it work so smoothly in the prototype?

[smbea]

Following our UX discussion, there are still some other things we could clear up:

• Behaviour of catch events vs (interrupting) boundary events: since we allow changing between boundary events to intermediate catch events, should we keep an element for each? It may be redundant but I think it's fine to keep both since the triggered action (autoPlace, create mode) is different.

Screen.Recording.2023-01-17.at.14.56.25.mov

• Previously, we were removing the append option from the context pad for elements that can't have outgoing connections (see ongoing PR) but since we changed our perspective on append, should we keep the option to append? Maybe makes sense for event subprocess. Does it make sense for end event?

Screen.Recording.2023-01-17.at.15.03.33.mov

[nikku]

Behaviour of catch events vs (interrupting) boundary events

I'm aware of that case and would keep it as is.

Maybe makes sense for event subprocess. Does it make sense for end event?

We could go either way about this, but we should be consistent: Either we show the menu for all flow elements (end, event-sub + others) or only others. Intuitively I'd not show for both (end, event-sub) for now.

Also: Should we show it for elements where the context pad is conclusive? Event-based gateway is such a candidate.

[smbea]

Also: Should we show it for elements where the context pad is conclusive? Event-based gateway is such a candidate.

I'd say we can keep it initially and we can do some refining after the initial PR (#1802) has been merged. Wdyt?

[barmac]

I was surprised to learn that we cannot add text annotation via the append menu. Perhaps that could make sense even for event subprocesses and end events.

[nikku]

I was surprised to learn that we cannot add text annotation via the append menu. Perhaps that could make sense even for event subprocesses and end events.

Let's log this as a follow up, too. Makes sense to annotate from there, too.

[barmac]

I was surprised to learn that we cannot add text annotation via the append menu. Perhaps that could make sense even for event subprocesses and end events.

Let's log this as a follow up, too. Makes sense to annotate from there, too.

Created as #1806