jk/color cycling

[jkrumbiegel]

• reorder wong colors and default markers to be more pleasing
• first implementation of attribute cycling

[aramirezreyes]

I would like some guidance to try and help with this.

In particular I wonder about the failing test:

It seems like the call to scatter(fig[1,1]) fails to inherit the settings from the Figure, whereas a call to scatter! does not. Where should I look for pointers? As scatter and scatter! seem to be automatically generated, couldn't track back all the function calls.

[jkrumbiegel]

This is all happening in the plot! methods of which there are many. scatter just turns into plot(Scatter... etc, so look for plot methods with a type as one of the first arguments. I forgot what the file was named, and I'm on mobile :) The pipeline is a bit tricky to understand honestly.

So anyway, where I got stuck was to correctly inherit what should be inherited, but also to not reuse or connect observables together when inheriting, because if all lines use the same color attribute observable, things get crazy.

[mschauer]

You have 7 colors, 8 marker attributes and 5 line styles? That's all co-prime 👍

[jkrumbiegel]

It also depends how one cycles these things. I think I'd prefer to offer different cycle options, but it gets tricky. For example, do you cycle the colors with the first linestyle, then the second? Or do you cycle them together.

[mschauer]

If they cycle together then there is most chance to tell things apart because they "differ in more than one way", so that is a sensible default, and by being co-prime the full pattern repeats only after 7*5 (lines) or 7*8 (markers), 7*5*8(lines with markers)
steps

[piever]

I confess I am generally very fond of explicit approaches, so maybe my view is a bit extreme here, but wouldn't it be easier to have a type

struct Default
    n::Int
end

such that Default(n) get's converted to the n-th (with cycling) element of the default palette, for any attribute with an available palette?

scatter!(x, y, color=Default(1))
scatter!(x, y, color=Default(2))

is not so hard to write (esp. if we find a shorter word than Default, maybe Cycle(1)). That way we do not have to guess what the user is cycling and the implementation is probably very straightforward.

EDIT: actually, color=1 currently errors, so we could also consider that option.

[Datseris]

just chiming in here to say: one things I like from PyPlot is not only that it has a color cycle, but also that I can set my own color cycle via theming. E.g. I can set it to be ["teal", "black"] and once I do this

plot(x, y)
plot(x, z)

the first line will be "teal" and the second "black". Would be nice to allow this here as well!

[jkrumbiegel]

#741