Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to deal with plotting functions where positional args are not necessarily x and y #97

Closed
jkrumbiegel opened this issue Oct 12, 2020 · 4 comments · Fixed by #505
Closed

Comments

@jkrumbiegel
Copy link
Member

For example, all the flipped versions of plotting functions, like a vertical density, or a horizontal boxplot. I guess AlgebraOfGraphics would not necessarily complain about such a function, but the axis labels would be wrong if the assumption is that the first argument is always x and the second always y. How can this be made generic?

@piever
Copy link
Collaborator

piever commented Nov 17, 2020

I think somehow there should be a trait on recipes that tells you the orientation. Alternatively, this could be done upstream, and AbstractPlotting could support working with named arrays (AoG uses NamedDims) and take care of the automatic axis labeling. It's already a concrete problem, for example in QQNorm one already gets the label on the wrong axis.

@haberdashPI
Copy link
Contributor

haberdashPI commented Jun 6, 2022

Just ran into a case where I'd like to be able to do this. I'm interested helping to move this forward.

I think somehow there should be a trait on recipes that tells you the orientation

Can you elaborate on this point a bit? As I understand it, this is already true. E.g. one can simply check that :orientation in propertynames(plot) && plot.orentation == :horizontal, since this is the keyword all existing Makie recipes use to indicate a flipped axis.

@jkrumbiegel
Copy link
Member Author

I'm pretty sure not all but that's something we wanted to clean up as well

@haberdashPI
Copy link
Contributor

Ah, got it. Well, a simple fix for the time being would simply be to define the check I proposed in a method and allow the exceptions to define a specialized method. Right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants