Adding Custom Text Labels to Edges in GLSP: Draggable and Editable

[Abhay0294]

Hi,

I have the following requirement:

1. There should be a text on the edge (for reference attached a snap).
2. The added text on the edge should be attached to edge by default, but at the same time it should be free to drag anywhere on the GLSP canvas.
3. The edge text should be editable as well.

Requesting the inputs for the implementation.

[planger]

Hi,

to place a label relative to an edge, you typically add a GLabel as a child of an GEdge and control its automatic positioning with the edgePlacement property in the GLabel of the edge. This is documented in the GLSP Client-side Layouting section.

This label can be made editable as any other label with the editLabelFeature in the di.config.ts:

configureModelElement(context, 'label:type', SLabel, SLabelView, { enable: [editLabelFeature] });

and an OperationHandler for the ApplyLabelEditOperation on the server to process label edits.

If you want to make this label movable, then you have to customize several places and store its user-defined position relative to the edge. I guess there are two general approaches:

1. Make the edge label essentially independent of the edge and control its positioning in custom code. That is, put the edge label inside of a separate node and make the node movable and control the positioning of the node in client-side command handlers (e.g. when the user drags something and by that changes the edge route, you'd have to move the node alongside it) and change bounds operation handlers on the server. Of course you'd need to compute a default location relative to an edge yourself either by a custom layouter on the client or already on the server when creating the GModel.
2. Customize the default change bounds tool so it allows to move edge labels, setting custom positions of the label relative to the edge and a customized layouter that can take custom positions relative to the edge into account, as well as server handlers to store and process those custom positions.

Both should be possible, but isn't straightforward. I think I'd go with approach 1, as it would interfere less with default behavior and you'd have everything under your control.

[planger]

Hi,

if you want to use the frameworks automatic positioning of an element relative to an edge, the direct child of the edge needs to have the edgePlacement property and have the edgeLayoutFeature enabled, which is true by default for labels, but not for compartments. This is because, usually you'd put your label as a direct child of the edge.

The class responsible by default for positioning edge labels is the EdgeLayoutPostprocessor. As you can see in the code, it'll get only active for each element that isEdgeLayoutable.

export function isEdgeLayoutable<T extends SModelElement>(element: T): element is T & SChildElement & BoundsAware & EdgeLayoutable {
    return element instanceof SChildElement
        && element.parent instanceof SRoutableElement
        && checkEdgeLayoutable(element)
        && isBoundsAware(element)
        && element.hasFeature(edgeLayoutFeature);
}

So I recommend to either put the label as a direct child, or make the adjustments to your compartment configuration so the code above gets active for your compartment. To get a good overview of what is happening, it is probably best to debug through the code I linked above for your use case to see what is going on. If needed, you can always customize the EdgeLayoutPostprocessor by rebinding it with your implementation.

I hope this helps!

[Abhay0294]

Thanks a lot @planger, it worked.

[Abhay0294]

Hi @planger,

Below is one test case scenario:

label-Edge-layout-Issue.mp4

The observations are:

1. When 2 nodes are connected to the same target.[as shown in the video above]
2. Initially when the edge length is small, both the edge labels are placed differently [edge labels positioned at 0.5d from the edge start]
3. As we are increasing the edge length of both edges, there comes a point when the labels gets overlapped.

Requesting your inputs to handle such scenario.
My requirement is when we encounter such scenario, then the labels should be placed differently, allowing the user to view the labels properly.

[planger]

From the top of my head, I think the only approach is to customize the EdgeLayoutPostprocessor (i.e. rebind a custom subclass). But also with a custom EdgeLayoutPostprocessor it isn't really straightforward to handle as you don't have access in the EdgeLayoutPostprocessor to the other routes to even detect that two labels would be overlapping.

It may also be worth looking at eclipse-sprotty/sprotty#226 where we had a similar requirement to know the routes of other edges during the computation.

[Abhay0294]

Thanks @planger , will try once as per the above inputs.

[Mc-Hoyos]

For future reference, Sprotty does support movable edge labels: eclipse-sprotty/sprotty#411.

The problem is that in GLSP, at least in Java, the org.eclipse.glsp.graph.GEdgePlacement does not include the 'moveMode' attribute (the GEdgePlacementBuilder does not provide it either). This is a simple fix to the GSLP Graph metamodel that could enable the moveMode feature.

I have successfully make a work-around by providing a custom 'EdgeLayoutPostprocessor' in the GLSP client, that overrides the 'getEdgePlacement' method and ads the moveMode if present in the element args. So in Java server:

GLabel nameLabel = ...
nameLabel.getArgs().put("moveMode", "free");

and in the client"

@injectable()
export class CustomEdgeLayoutPostprocessor extends EdgeLayoutPostprocessor {

    /**
     * Overrides getEdgePlacement to augment the placement with moveMode from element args.
     * This allows labels to specify moveMode via args without modifying their edgePlacement property.
     */
    protected override getEdgePlacement(element: SModelElementImpl): EdgePlacement {
        // Get the base placement from parent implementation
        const basePlacement = super.getEdgePlacement(element);
        
        // Check if element has args with moveMode and merge it
        if (hasArgs(element) && element.args['moveMode'] !== undefined) {
            const moveMode = element.args['moveMode'] as 'edge' | 'free' | 'none';
            return { ...basePlacement, moveMode };
        }
        
        return basePlacement;
    }
}

Create a module for the post-processor so we can add it to the container:

/**
 * Module that registers the CustomEdgeLayoutPostprocessor as an IVNodePostprocessor.
 * This enables edge labels to specify moveMode via args property.
 */
export const customEdgeLayoutModule = new ContainerModule(bind => {
    bind(TYPES.IVNodePostprocessor).to(CustomEdgeLayoutPostprocessor);
});

And then you can add the module to your client, but make suer to remove the default EdgeLayoutPostprocessor module.

export function initializeWorkflowplusDiagramContainer(container: Container, ...containerConfiguration: ContainerConfiguration): Container {
    let result = initializeDiagramContainer(
			container,
			...,
			customEdgeLayoutModule,
			...,
			...containerConfiguration);
    result.unload(edgeLayoutModule);
    return result;
}

Finally, you also need to enable the move and select feature for your model elements:

   configureModelElement(context, 'label.movable:type', SLabel, SLabelView,
			 { enable: [editLabelFeature, moveFeature, selectFeature] });

[tortmayr]

@Mc-Hoyos Thanks for raising this.
Seems like there is indeed a diff between what sprotty supports and what we offer in GLSP.
I will evaluate and trace this. THe goal is to eventually be aligned again.