New Demo: Elements Grouping

[kumilingus]

How to group several elements into a single entity? And how to ungroup them?

See this CodePen featuring custom ui.Selection handles, embedding graph feature, and stopDelegation interactivity option.

[mwanagosos]

@kumilingus A very cool demo, thanks. I have a question about a particular behavior:

1. Group several elements
2. Try repositioning the group by clicking on the red field and dragging it.

The above does not reposition the group, but causes the blue field to appear. It means we are selecting multiple new blocks instead.

Is that intentional? Is there a way to change it so that dragging the red field changes the position of the whole group?

[kumilingus]

It was an intention. If you want the group itself to be draggable remove the pointer-events: none attribute from the root element of the group.

[mwanagosos]

What would be the preferred way to implement a feature of collapsing a group of elements so that they take less space? I would also like to give a group a label.

[kumilingus]

Here's an example of a collapsible group with a label.

[alexandernst]

Is there a way to group the elements on the SVG level? The current demo creates a <g> element for the group and two more <g> elements for the square and the circle and then inserts the 3 elements in the <svg> element:

<svg>
  <g></g> <-- group element
  <g></g> <-- square
  <g></g> <-- circle
</svg>

What I'd like to achieve:

<svg>
  <g> <-- group element
    <g></g> <-- square
    <g></g> <-- circle
  </g>
</svg>

My intention is to be able to attach a clip path to the group element in order to hide overflowing elements that are embedded inside the group element. E.g:

    group

     │
     │
     │
     ▼
┌────────────────────────────┐
│                            │
│                            │
│   ┌────────┐               │
│   │        │        ┌──────┼──┐
│   │        │        │      │  │ ◄─────────
│   │        │        │      │  │ this part
│   │        │        │      │  │ should be
│   └────────┘        │      │  │ hidden
│                     └──────┼──┘
│        ▲                   │
│        │                ▲  │
│        │                │  │
│        │                │  │
└────────┼────────────────┼──┘
         │                │
         │                │
         │                │

      element      element

If inserting elements into another elements on the SVG level is not possible, is there any other way I can achieve this?

[kumilingus]

That's the kind of grouping we would like to implement eventually :) It's good from a performance aspect too - you can modify a single transform attribute of the group and move several elements at the same time.

Before that happens...

1. You could create an SVGGroupElement <g> and append the cellViews into it manually. It will break only the cells z-indexes (the current z and whenever the z changes you'd have to re-append it to the <g> or use sorting NONE. Everything else should work the same.

2. You could take advantage of the half-done PaperLayer API as shown here:

CodePen.

• The z-indexes of grouped cells will have a new stacking context (the group itself).
• If we add an API to add/remove/change/sort layers, the layer groups can be added dynamically along with the rectangle groups and bind together to update the clipPath whenever the rectangle group moves (create a custom Class from the dia.PaperLayer)
• At this point we are not 100% sure, but if we allow layers to be nested, it could serve as a great foundation for the grouping feature.

[alexandernst]

Ohh!! I was just about to ask about the performance aspect of this :)

The entire PaperLayer seems nice, but I have a few questions:

1. What is the current state of this feature? Can it be considered API-stable?
2. Follow up question: if I were to patch the library to support nested layers, how painful would it be? I'm asking because I do plan using this for nested layers, and I must plan accordingly. If it will be moderately-to-very painful, I'd rather try to make a compromise on the design of what I'm trying to achieve until (nested)Layers is fully implemented.
3. I see that the elements are nested inside g elements, but the coordinates are still "global". Is that a bug or a feature?

[kumilingus]

1. It's pretty stable. It was written with the bigger picture in mind (since is not official yet, it can change slightly).
2. I think the nested layers are going to be painful, but I usually expect the worst 😄. Perhaps the rendering order has to be adjusted for the nested groups (a parent group will have to be rendered before children).
3. It's not a bug. It was only simpler to do it this way. It requires an extra work because the cellViews have to calculate their positions relatively to the group they belong to - right now its always from { x: 0, y: 0 }).