Extending styles without forking Cytoscape

[danprince]

We'd love to use Cytoscape.js as part of a project, but one of the blockers is not having a clear way to extend the rendering functionality.

For example, we'd like to add a "bullseye" decoration, which would render a smaller inset version of a node's shape, with its own size and color. This would also involve adding additional style properties.

node {
  bullseye-size: 90%;
  bullseye-color: red;
  bullseye-width: 25%;
  bullseye-height: 25%
}

Currently it seems like the unrecognised properties aren't parsed (or at least they aren't accessible through pstyle) and the best way I can see to augment the renderer involves patching out drawNode. For example:

let CanvasRenderer = cytoscape("renderer", "canvas");

let drawNode = CanvasRenderer.prototype.drawNode;

CanvasRenderer.prototype.drawNode = function(context, node, ...args) {
  drawNode.call(this, context, node, ...args);
  // Use context to draw bullseye here above the node...
};

The problem with this approach is that the only control is whether the additional decorations are rendered above or below the original renderer's node. This means we can't render the bullseye above the node body, but below the label.

The simplest way to achieve this would be to fork Cytoscape and add the appropriate properties and renderer handling for them.

If any of these kinds of properties would be accepted upstream, then we'd be happy to contribute them.

• Scale (some way to scale up an entire node—width, height, and label size)
• Bullseye (a separate node shape inside the node)
• Margin (gap between outside of a node and the connection points)
• Outline (a separate border, only really used for interaction styles)
• Flags (an outer layer of pie segments, see: https://docs.kumu.io/guides/decorate/flags)

Some of these go beyond rendering concerns and into the interaction layer. For example scale and margin both change the overall shape with respect to layout and connection positions.

The ideal scenario would be an extension point that would allow us to register additional styles and extend the existing canvas renderer for drawing them, but definitely recognise that this might just be an awkward API to design for a fairly limited use case.

Good to start that conversation either way, so that we can get some idea of how to move forwards!

[maxkfranz]

Hi Dan,

Adding visual style properties to the library, without modifying the library directly, is not likely to be pragmatic. A feature that merits a style property ought to be integrated into the library itself.

Let's start by enumerating your proposed features with questions like these:

Which of these features could be accomplished on top of the library? Conversely, which features would absolutely require direct integration in the library?

Which features could be new extensions? Could some features be accomplished already, with a combination of existing style properties and extensions?

Looking forward to your response,

Max

[danprince]

Thanks @maxkfranz!

Let's run through them.

• Scale
  I don't see a way for this to be done through an extension. It would need all the styles to be parsed then multiplied by the scale as the final step. The resulting changes affect the way elements are rendered, but also their dimensions for calculating edge points and hit tests etc.

• Bullseye
  Without writing a new renderer, there's no way an extension can hook in to render between the node body and label, so again, I think this needs to be direct integration. Visually you can make a bullseye with a border and a background colour, but it's important that this is a distinct concept, so that nodes can have borders, background colours and bullseyes.

• Margin
  Similar kind of story to scale, margin affects the bounds of the shape (changes edge endpoints).

• Outline
  This is functionally very similar to a border, but we use these outlines to signal user interaction, and it's important that they are a distinct concept. Outlines need to live outside the border, but inside the underlay. Doesn't affect the bounds of the node, so it's easier to add with an extension, but we still don't have enough rendering control to draw them below the label.

• Flags
  This one is tricky. I see that the pie styles were deprecated and I'd be cautious about suggesting such a similar feature for the core library, however the way we'd prefer to use flags is more data-driven. Rather than specifying the individual segments by index, the usage would look more like:

  node {
    flag: "tags"; /* tags is the name of a property in `data` which is an array */
  }

  Then a "flag segment" is assigned to each distinct value across all the "tags" values. More detail on how you can extend this syntax to control colours in the Kumu docs.

  Not sure whether this is potentially too high-level of a feature for Cytoscape though. Also runs into the same issue of not being able to render flags below the text label but above the underlay etc.

[maxkfranz]

Have you had the opportunity to review all the style properties in depth?

The SBGN stylesheet demo on the top of the documentation gives a good example of creating a very customised style using only existing features.

[danprince]

Thanks @maxkfranz! We've had a good look through the style properties and that's a big part of the reason we're still keen to use Cytoscape.

We've been building Kumu for the past 10 years or so, with a pretty similar model to Cytoscape.js (property graphs, selectors, style rules) but our renderer is tightly coupled into the core of the product in a way that makes it hard to re-use it in adjacent explorations.

The great work you folks have been doing here means you're already 90% of the way towards offering the visual flexibility from Kumu, and we would love to be building on (and contributing to) an open source project, rather than our in-house library.

The last 10% is where it's tricky, because we're not trying to create a specific style (like the SBGN one), but instead trying to approximate all the combinations of styles that we're already used to using with Kumu.

[maxkfranz]

How about we start with the outline, since it’s the simplest, and take it from there?

[danprince]

Sure. Happy for us to just land a PR directly or is it useful to kick off with an issue describing how we see the outline style property working?

[maxkfranz]

We’ll need to make an issue for the milestone anyway, so we might as well start with that.  It will be good practice for the other, more complex features, even though the outline specification would be simple. In future, the issues will be increasingly important for the other features, to avoid unnecessary or duplicated effort.  Imagine implementing an entire costly feature, and then later discovering that it has to be redone.On Aug 17, 2023, at 03:13, Dan Prince ***@***.***> wrote: Sure. Happy for us to just land a PR directly or is it useful to kick off with an issue describing how we see the outline style property working? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[6illes]

We are interested in styling the edge lines with "border-xxx" attributes (color/opacity/width/...).
Any way to do it as of today ?

[maxkfranz]

Yes. There's a way to do it as of today, because every day is a good day for a pull request.

[6illes]

Excuse my french, would you please explain how I can do this ?

[6illes]

Actually, we use cytoscapejs for a network weathermap.
We define links (edges) between routers (nodes). The "label" is use to show the load. The "lines" are colored based on intensity.
And we have to differentiate the edges. So we would like to use different "border" colors for the "edges".
Does it make sense ?

[maxkfranz]

It sounds like you could use an approach similar to the existing overlays/underlays with some clipping: https://js.cytoscape.org/#style/overlay

Looking forward to the PR