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

Inconsistent Scale Management #2851

Closed
billdenney opened this issue Aug 23, 2018 · 4 comments
Closed

Inconsistent Scale Management #2851

billdenney opened this issue Aug 23, 2018 · 4 comments

Comments

@billdenney
Copy link
Contributor

I recently upgraded to ggplot2 version 3.0.0, and I was surprised by the change to discrete scales where I was now getting a yellow value (near-invisible on a white background). As I was looking into how to change the default back to the prior behavior, I noticed inconsistent handling of colour scale types with ggplot2 version 3.

  • In scale_colour_continuous() a new type argument along with an option managed by getOption("ggplot2.continuous.colour", default="gradient") determines how the scale is determined.
  • scale_colour_ordinal() is assigned to scale_colour_viridis_d(), but it is not mentioned in the manual.

If global options will be the way that default scales are managed in the future, could a new help page be added for all the options that control ggplot2? (My preference is that this will be moved away from.)

Can the default function used to control each scale be defined in a single help page to assist with finding how to change the default behavior?

@hadley
Copy link
Member

hadley commented Aug 23, 2018

Can you please provide a minimal reprex (reproducible example)? The goal of a reprex is to make it as easy as possible for me to recreate your problem so that I can fix it: please help me help you!

If you've never heard of a reprex before, start by reading "What is a reprex", and follow the advice further down the page. Please make sure your reprex is created with the reprex package as it gives nicely formatted output and avoids a number of common pitfalls.

@hadley hadley added the reprex needs a minimal reproducible example label Aug 23, 2018
@billdenney
Copy link
Contributor Author

This is a documentation and feature consistency issue not a function issue.

When I think of the colour scales available, I think of scale_colour_continous(), scale_colour_discrete(), and scale_colour_ordinal(). I believe that these have a hierarchy of controlling functions and different choices within as follows:

  • scale_colour_continuous()
    • scale_colour_gradient()
      • scale_colour_date() and scale_colour_datetime()
    • scale_colour_gradient2() and scale_colour_gradientn()
    • scale_colour_grey()
    • scale_colour_viridis_c()
  • scale_colour_discrete()
    • scale_colour_brewer()
    • scale_colour_distiller()
    • scale_colour_hue()
    • scale_colour_viridis_d()
  • scale_colour_ordinal()
    • Choose one from under scale_colour_discrete()
  • scale_colour_identity()
  • scale_colour_manual()

The top-level functions should have a generally similar argument structure as much as feasible to prevent the need to re-learn each function individually. There are required differences given the differences in the way that graphics are selected underneath.

They are not documented similarly currently; scale_colour_ordinal() is mentioned nowhere in the documentation (other than the index).

They are not managed similarly:

  • scale_colour_continuous()
    • has a new type argument where you can choose between "viridis" and "gradient",
    • the type option is controlled by the global option "ggplot2.continuous.colour"
      • This option naming breaks the general trend for ggplot2 to work with both New Zealand and American spellings.
    • has its own documentation page.
  • scale_colour_discrete()
    • is directly assigned scale_colour_hue() (
      scale_colour_discrete <- scale_colour_hue
      ) and does not have a type argument,
    • therefore has no option controlling the selection of the default, and
    • has no documentation other than the index.
  • scale_colour_ordinal()
    • is directly assigned scale_colour_viridis_d() (
      scale_colour_ordinal <- scale_colour_viridis_d
      ) and does not have a typeargument,
    • therefore has no option controlling the selection of the default, and
    • has no documentation other than the index.

Feature Consistency

I think that the behavior of scale_colour_continuous(), scale_colour_discrete(), and scale_colour_ordinal() should be standardized to all do the same from the following list:

  • Have a type argument (or not).
    • My preference is not to have the type argument because it makes more than one way to change the default scale_ and the single method of "assign your favorite like scale_colour_continuous <- scale_colour_gradient or scale_colour_continuous <- scale_colour_viridis_c" seems more straight-forward and more extensible.
  • Have a global option extracted by getOption() (or not).
    • My preference is not.

Documentation Consistency

A few hours ago, it took digging into the code to figure out how to change the default scale_colour_ordinal() by assigning my preference to it. Can the documentation be updated to:

  • Include a page with the top levels from the hierarchy above adding all the other top-level functions like scale_fill_continuous(), scale_shape_discrete(), etc.
  • On that top-level scale page, describe how to control the functions to select the default (with the decisions from the feature consistency section above).
  • Link all the other scale_* documentation back to that top-level page.

@clauswilke
Copy link
Member

Related: #2691

@teunbrand
Copy link
Collaborator

In #5946 we moved away from the type argument in favour of theme-able default palettes.
The type argument is still there for backward compatibility, but the 'preferred path' to setting default colours is now consistent.
As such, I think we can mark this issue as completed.

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

No branches or pull requests

5 participants