Conversation
fenjalien
left a comment
There was a problem hiding this comment.
We'll need to write a specification of what a decoration function should expect to receive and what it is expected to return.
What do you think of blocking this until we work on modifiers?
340ad25 to
1d1f8ad
Compare
|
@fenjalien I've updated the API. This new modifier implementation is meant to completely replace the The PR is still very WIP but should give a first idea. It is a better implementation than what I wrote some information to the connected issue. |
1d1f8ad to
2389e17
Compare
2389e17 to
ea93e66
Compare
|
Rebased. If we merge this, we can implement marks on top of this. I prefer not touching the mark implementation before we agree on a modifier/decoration implementation. If we want to support outputting extra geometry from modifiers, we should discuss how to do that. The current interface does not allow this. To add support, the |
|
I'm happy to continue using I would really like to get on with this but I want to get the docs website up properly and I'm struggling to find time for it. |
2ab9f11 to
b845272
Compare
b845272 to
f4cf9a0
Compare
Implements #465.
This PR is a WIP implementation on how to implement decorations as style option for all (but grid and mark) elements.
The idea:
decorationsdictionary that can be modified to add custom decorations.This allows for a function like
register-decoration(...)for plug-ins (same plan as with custom marks; not added yet).decoration: ..for elements. Element paths get decorated before adding marks, which allows for styled paths to have marks.Demo of the

waveandlinearizemodifiers: