Add append element

[smbea]

Closes #1801
Depends on #1807

How it looks:

Uploading Screen Recording 2023-01-12 at 13.46.56.mov…

Note:
I used the same approach as for icons as we do in align and distribute. It seems to be the best solution we have for now (maybe the svg updates could be automated in the future)

[nikku]

@smbea Any reason we're not using the ... icon? As far as I am aware the icon you chose is a web modeler extension, specifically to append a new connector. I'd not want to incorporate it into the core.

If you want to I can dig up earlier discussions on "which icon to choose", where we settled on "...".

[smbea]

@smbea Any reason we're not using the ... icon? As far as I am aware the icon you chose is a web modeler extension, specifically to append a new connector. I'd not want to incorporate it into the core.

If you want to I can dig up earlier discussions on "which icon to choose", where we settled on "...".

I wasn't aware this is a connectors only icon (since it looks like 2 elements connected, i thought it also applied for general append). I didn't see this in the original issue, but I exchange it now for the '...'

[philippfromme]

Are we planning to add a keyboard shortcut similar to R to open the replace menu? Could really speed up modeling for expert users.

[smbea]

Are we planning to add a keyboard shortcut similar to R to open the replace menu? Could really speed up modeling for expert users.

I would go for a 'A' keyboard, would be really empowering for keyboard users. But I would rather add it in a separate follow up PR to keep this simpler.

[philippfromme]

I found two quirks:

1. You can append elements that can only be connected in the opposite direction
2. You can append elements that cannot be connected at all

Are we aware of this?

[smbea]

I found two quirks:

1. You can append elements that can only be connected in the opposite direction
2. You can append elements that cannot be connected at all

Ooops. I will have another look at this

[nikku]

#1802 (comment)

We absolutely want that to be keyboard accessible.

In the prototype we use A (works as append with element selected, create otherwise) and N (for create new element).

[nikku]

@smbea Please also double-check existing bugs on the prototype. We want to make sure those don't re-open in the Camunda Modeler.

[smbea]

Some comments on the recent changes:

• icons: you are right @nikku, I also pondered that. I started with moving the ones added here to lib/icons. I can also move the ones already present for align/distribute but I'd rather do it in a follow up PR as to not crowd this one

• appending elements that can't be connected: Following this comment I removed the option to append elements that can't be connected. Since there isn't a canConnect utility that takes only the element type as argument, I tried to catch all these cases myself. I also see there was some discussion on boundary events and if/how they should appear on the append menu. Personally, I don't see why we would want to keep elements that can't be connected but we can have a sync on this.

• keyboard shortcut: will follow up on this. It's already a task in the main issue.

By accident.

[nikku]

In the spirit of integrating things incrementally, this can be implemented on top, no?

Yes, of course. Let's just ensure we don't at least evaluate it at some point.

I've added it to the epic just to be sure.

[smbea]

In order to make it a little simpler to look at this PR, I extract the element factory fixes to #1807.

[smbea]

Ready for review again. If you feel like this is a solid starting stage but see possible improvements, we can create follow up issues for it and them to the possible follow ups section here 🙂

[nikku]

Thanks for this contribution! Very nice:

• Integration with rules
• Improved handling of icons
• Solid test coverage
• Really intuitive modeling

---

To highlight one thing I love how natural this feels to me (auto place vs. manual placement), i.e. considering the "non-interrupting boundary" placement here:

---

If I had one wish then it would be to be less strict regarding when we show the menu. i.e. for link throw events:

If we combine "showing it in more places" with #1621 you could argue that creating a (matching) link catch event (or creating a matching catching event for whatever throw event is selected) could be the primary action provided to a user. :)

Great work overall.

[smbea]

Thanks @nikku. After having the first iteration of this done, I would love to do some refining and possibly do it in the context of semantic ordering - I agree it would be awesome to have this