Open fenjalien opened 7 months ago
This would effectively resolve #446
Idea we've discussed:
Allow to register path modifiers at the context object. So libraries can add their custom path modifiers, like with user definable (define-mark
) marks.
Elements have a modifier:
style key. A modifier can be the name of a modifier function or a dictionary containing the name + style arguments. A user can pass a list of modifiers to an element. All modifiers share some common keys like begin
and end
to denote the sup section of a path to apply the modifier to.
The modifier API replaces the current path decoration lib.
There will be a separate apply-modifier(.., body)
function to apply a modifier to a body.
A path modifier is a function with the following signature (ctx, style, segments, close) -> segments
that gets called by the internals.
A user can provide custom modifier functions.
Considering what I've detailed in #467 I don't agree. Restricting modifiers to be like this feels like a waste of potential. Decorations should really be a subset of modifiers.
You currently have to wrap the path that you want to decorate with another decoration function which effectively modifies the output drawables of the path. Instead (or alongside) I would prefer the option to set a path's decoration through a style key:
Styling options for the decoration could be given further as a dictionary similar to how mark styling works.