Register default scales via themes

[clauswilke]

As previously mentioned in the discussion of #2239: It would be nice if default scales could be set via themes.

Currently, default scales are defined as functions that are named scale_aesthetic_data-type(), where aesthetic is the name of the aesthetic and data-type represents the data type, i.e., continuous, discrete, date, etc. For example, scale_colour_discrete() is the default scale function for discrete colors.

The definition of these defaults is distributed all over the scales code, because for some scales the default scale is the only scale that exists (example:

ggplot2/R/scale-alpha.r

Line 31 in 77fc5c7

scale_alpha_discrete <- function(..., range = c(0.1, 1)) {

) whereas for others there are multiple possible ones and hence one is set as the default (example:

ggplot2/R/zxx.r

Line 6 in 77fc5c7

scale_colour_discrete <- scale_colour_hue

).

It would be nice if there were a way to change the defaults other than to change the global function definitions, and in particular if the defaults could be linked to the theme. For example, the theme could have an entry default_scales = list("scale_color_discrete" = scale_color_hue, "scale_color_continuous" = scale_color_gradient, ...) that lists the default scales to be used with this theme.

In terms of implementation, I see two problems, and it's not clear to me how much of a hurdle they might be. First, the code that searches for the default scales currently doesn't have access to the theme:

ggplot2/R/scale-type.R

Lines 1 to 20 in bcc3ae5

	find_scale <- function(aes, x, env = parent.frame()) {
	if (is.null(x)) {
	return(NULL)
	}
	type <- scale_type(x)
	candidates <- paste("scale", aes, type, sep = "_")
	for (scale in candidates) {
	scale_f <- find_global(scale, env, mode = "function")
	if (!is.null(scale_f))
	return(scale_f())
	}
	# Failure to find a scale is not an error because some "aesthetics" don't
	# need scales (e.g. group), and it allows others to extend ggplot2 with
	# their own aesthetics
	return(NULL)
	}

It is called from this function:

ggplot2/R/scales-.r

Line 91 in bcc3ae5

scales_add_defaults <- function(scales, data, aesthetics, env) {

which is called from here:

ggplot2/R/layer.r

Line 214 in a7b3135

scales_add_defaults(plot$scales, data, aesthetics, plot$plot_env)

and here:

ggplot2/R/layer.r

Line 274 in a7b3135

scales_add_defaults(plot$scales, data, new, plot$plot_env)

Second, it's not immediately clear to me whether we even have the complete theme by the time these functions are called. They are ultimately called in plot_build() here:

ggplot2/R/plot-build.r

Line 48 in 3f63d62

data <- by_layer(function(l, d) l$compute_aesthetics(d, plot))

If by that time the entire theme is assembled, then I assume it could be handed down through all these functions to the point where the scale is looked up. Otherwise, this proposal would be infeasible.

[clauswilke]

This function would also have to be modified:

ggplot2/R/scales-.r

Lines 110 to 121 in bcc3ae5

	scales_add_missing <- function(plot, aesthetics, env) {
	# Keep only aesthetics that aren't already in plot$scales
	aesthetics <- setdiff(aesthetics, plot$scales$input())
	for (aes in aesthetics) {
	scale_name <- paste("scale", aes, "continuous", sep = "_")
	scale_f <- find_global(scale_name, env, mode = "function")
	plot$scales$add(scale_f())
	}
	}

It is similarly called from plot_build(), so this shouldn't create any new complications.

[baptiste]

Just for completeness I'll re-iterate my personal preference for a revised scale_colour|fill_xx interface.
Currently we have this situation,

apropos("^scale_color_")[-c(5,7,14,22,23)]
 [1] "scale_color_brewer"             "scale_color_calc"              
 [3] "scale_color_canva"              "scale_color_colorblind"        
 [5] "scale_color_continuous_tableau" "scale_color_distiller"         
 [7] "scale_color_economist"          "scale_color_excel"             
 [9] "scale_color_few"                "scale_color_fivethirtyeight"   
[11] "scale_color_gdocs"              "scale_color_gradient_tableau"  
[13] "scale_color_gradient2"          "scale_color_gradient2_tableau" 
[15] "scale_color_gradientn"          "scale_color_grey"              
[17] "scale_color_hc"                 "scale_color_hue"               
[19] "scale_color_pander"             "scale_color_ptol"              
[21] "scale_color_solarized"          "scale_color_stata"             
[23] "scale_color_tableau"            "scale_color_viridis_c"         
[25] "scale_color_viridis_d"          "scale_color_wsj"

where besides the distinction discrete/continuous I would argue that the essential difference is the palette. An alternative description might be a generic scale_colour_discrete/continuous(palette = "grey"), and in this form I would rather agree that "grey" could nicely fit in the theme description.

The interface might require a new kind of object to cater for all cases – a string to refer to built-in palettes, a function (potentially a functor) e.g for user-defined gradient/gradient2/gradientn and their parameters (midpoint, NA, etc.).

To me this feels more natural, and more in line with other design choices such as scale_x_continuous(trans = "sqrt").

The current array of special-case functions could still coexist, similarly to scale_x_log10.

[hadley]

I would love to see an implementation of this to see how feasible it is.

[clauswilke]

@cpsievert Would you be interested in trying to take this on? I don't have the capacity right now to tackle this.

[cpsievert]

@clauswilke I have other priorities at the moment, too. I don't think this should necessary block #3833, though. If there's some reason why it should, let me know, and I'll try and find time to look into this.

[clauswilke]

Agreed. Just think about whether your proposed API is right if we assume at some point scales can be set from the theme. This may or may not be the case. I haven't thought it through carefully.

[alanocallaghan]

Second, it's not immediately clear to me whether we even have the complete theme by the time these functions are called.

The theme is by default an empty list when compute_aesthetics is called. If a theme has been added to the plot it's not empty but that's clearly not the case being targeted.

I've not checked in detail but it seems the complete theme is built by

ggplot2/R/theme.r

Line 444 in 660aad2

plot_theme <- function(x, default = theme_get()) {

when it's called in ggplot_gtable.ggplot_built

ggplot2/R/plot-build.r

Line 166 in 660aad2

theme <- plot_theme(plot)

I would assume you could build the theme during ggplot_build instead. Moving it breaks 2 theme tests (these ones:

ggplot2/tests/testthat/test-theme.r

Lines 219 to 227 in 660aad2

	p <- ggplot_build(qplot(1:3, 1:3) + theme(text = element_text(colour = 'red', face = 'italic')))
	expect_false(attr(p$plot$theme, "complete"))
	expect_equal(p$plot$theme$text$colour, "red")
	expect_equal(p$plot$theme$text$face, "italic")
	p <- ggplot_build(qplot(1:3, 1:3) +
	theme(text = element_text(colour = 'red')) +
	theme(text = element_text(face = 'italic')))
	expect_false(attr(p$plot$theme, "complete"))

), but these are just checking that the built plot doesn't have a complete theme. That doesn't seem like a major issue, since the theme is completed when being drawn in any case. Of course it's quite probable I'm overlooking something (the tests are presumably there for a reason...).