Comment 67 for bug 165865

v5 tested

Issue 1: It appears that it's adding two copies of markers to the custom section when forking. One duplicate of the original one from the list as well as the correctly colored one.

Issue 2: If you assign a swatch (flat fill) to the stroke and then change that swatch color, the preview does not update.

> Yes this is by design and is consistent with the Color Marker extension. This seemed like the best way to allow the user to set the marker color and line color separately. There are some other complications of having auto updates - if you have several lines all using the same color marker, then you update one line color - do you then update all the marker colors or not ? Could add an option for this later.

I'd like to see other opinions, but I'm pretty sure the "average" user will expect all markers assigned to auto-update with the stroke color. The current implementation definitely is awesome and more powerful (and I like it), but something tells me that it will not be obvious enough and there will be a number of bug reports filed. As for the lines all using the same color marker, I say not to update the markers on other lines... but I imagine it would get ugly pretty fast with all the potential additional forking (if someone is using lots of markers and lots of different colored lines).

As for the gradient issues... Hmmm... I can't think of a really elegant solutions. Does this code at all interact with the function to create a marker from an object? If not, you could always detect if a gradient is on the stroke and just not change anything (with a note by the first preference that it doesn't work with gradients).