Skip to content

Fix calculation of theme defaults #2080

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

Closed
wants to merge 6 commits into from

Conversation

has2k1
Copy link
Contributor

@has2k1 has2k1 commented Mar 20, 2017

Issue
At plot time, the calculation of theme elements always fell back
to the default theme. As a consequence, the default theme would
leak into complete themes where some of the elements were
unspecified.

Solution
Be more specific when calculating the theme defaults.

Clean Up
theme_void was insufficiently specified. The solution exposed
missing elements that had to be specified.

Fixes #2058
Fixes #2079

@has2k1
Copy link
Contributor Author

has2k1 commented Mar 20, 2017

Tests fail due to assignments that relied on the problematic default theme inheritance that this PR got rid of.
The candidates should be (atleast) some of the results of

$ ag 'theme\$.+?<-'

@thomasp85
Copy link
Member

I don't think changing inheritance is necessary. All of these issues seems to come from the fact that theme_void() was incompletely specified, which is the root bug...

@has2k1
Copy link
Contributor Author

has2k1 commented Apr 4, 2017

I noticed that it was incompletely specified, but I think if you look closer the complete specification that would make the bug go away would imply that the elements themselves have no inheritance hierarchy. That is, even if you have axis.text = element_blank() you would also need axis.text.x = element_blank().

To be clear, these are the options for what could be meant by complete:

  1. Every possible element is specified.
  2. Every possible element is specified or have a parent that is specified.

This patch recognises the second definition, whereas your (@thomasp85) suggestion seems to imply the first. Also, if it is the first then the line that I removed/relocated would always be redundant as there wouldn't be any unspecified elements.

@crsh
Copy link

crsh commented May 25, 2017

Sorry to bother, but are there any news on this pull request?

@has2k1
Copy link
Contributor Author

has2k1 commented May 25, 2017

@crsh, I'll look into fixing the failing test case. The first time around, I expected to ask for help with a clearer question. I did not get to it.

@has2k1
Copy link
Contributor Author

has2k1 commented Jun 1, 2017

Fails on appveyor but not on travis.
@hadley , any reason for this? Do the visual tests only run appveyor? Otherwise, it seems like a legitimate failure.

@hadley
Copy link
Member

hadley commented Jun 2, 2017

@has2k1 Do you see the failure if you run locally?

@has2k1
Copy link
Contributor Author

has2k1 commented Jun 2, 2017

Locally, I get many failures (with/without this PR maybe something to do with fonts) but not the particular one that fails on appveyor.

@hadley
Copy link
Member

hadley commented Jun 2, 2017

@lionel- do you have any tools for debugging this sort of failure?

@lionel-
Copy link
Member

lionel- commented Jun 3, 2017

Nothing user-oriented yet, we definitely should add some UI for this.

IIRC, I generated a SVG from the faulty plot manually with vdiffr:::write_svg(), then I displayed the SVG contents with cat(), and compared the outputs on Travis and Appveyor.

We need a verbose expect_doppelganger() variant or option.

R/theme.r Outdated
@@ -380,7 +380,13 @@ theme <- function(line,

# Combine plot defaults with current theme to get complete theme for a plot
plot_theme <- function(x) {
defaults(x$theme, theme_get())
if (is.null(attr(x$theme, "complete"))) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When does this branch get triggered?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When using the default theme. The cases for the three branches respectively are.

ggplot(...) + geom_point()

ggplot(...) + geom_point() + theme_gray()

ggplot(...) + geom_point() + theme(...)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, got it. It might be slightly easier to read if you did:

complete <- attr(x$theme, "complete")

@hadley
Copy link
Member

hadley commented Jul 3, 2017

@karawoo can you please run the visual tests locally?

@has2k1 could you please add a bullet to NEWS? Are there some unit tests we could add to check that we don't fall back to the old (suboptimal) behaviour?

@karawoo
Copy link
Member

karawoo commented Jul 3, 2017

I get the same failing test that AppVeyor complains about. The title for theme-void.svg is being placed in the center rather than at the left, and it looks like the size of the title text and the amount of space between the plot and the title have changed too.

@hadley
Copy link
Member

hadley commented Jul 3, 2017

@has2k1 can you reproduce those issues locally yourself?

@has2k1
Copy link
Contributor Author

has2k1 commented Jul 3, 2017

I cannot reproduce the failing test.

Also, if I approximate the failing test with

df <- data.frame(x = 1:3, y = 1:3, z = c("a", "b", "a"), a = 1)
plot <- ggplot(df, aes(x, y, colour = z)) +
  geom_point() +
  facet_wrap(~ a)

plot + ggtitle("theme_void") + theme_void()

The title is still in the center.

For the speculation (my system is linux), given that on travis (linux) the test passes, and on appveyor (windows) it fails, could be an issue with the svg driver defaults between different systems. @karawoo, I think you can dismiss this as an explanation if the png and svg results of the code above are different.

@has2k1
Copy link
Contributor Author

has2k1 commented Jul 3, 2017

For creating a test, I do not know how wise it would be to mess with the default theme (a global variable) in the test suit.

@has2k1 has2k1 force-pushed the fix-theme-defaults branch from d8c5f0d to d6a5066 Compare July 3, 2017 21:50
@hadley
Copy link
Member

hadley commented Jul 5, 2017

@has2k1 it's fine. Just use on.exit() to restore. Alternatively, you could add a second argument to plot_theme that defaults to theme_get() but you could override in the tests (that's probably a better solution)

@has2k1 has2k1 force-pushed the fix-theme-defaults branch from a509a7d to 981caef Compare July 6, 2017 18:44
Copy link
Member

@hadley hadley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It sounds like @karawoo was saying that after this patch, the title is centred, but it should be left aligned. Can you please confirm?

@@ -163,6 +163,20 @@ test_that("Complete and non-complete themes interact correctly with ggplot objec
expect_false(attr(p$plot$theme, "complete"))
expect_equal(p$plot$theme$text$colour, "red")
expect_equal(p$plot$theme$text$face, "italic")

# The final calculated plot theme should not blend a complete theme
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please make this a separate test?

@karawoo
Copy link
Member

karawoo commented Jul 14, 2017

Yeah, that's what I was seeing with the title.

@has2k1 has2k1 force-pushed the fix-theme-defaults branch from 981caef to 6a4472d Compare July 14, 2017 23:20
@has2k1
Copy link
Contributor Author

has2k1 commented Jul 14, 2017

I've specified the title, subtiltle and caption text elements of theme_void so that they take on the same values as in the other themes. This should have theme_void maintain a similar overall arrangement. I am not sure if any more theme elements should be specified to get the tests to pass or to make the current appearance the new normal.

@hadley
Copy link
Member

hadley commented Jul 27, 2017

@has2k1 looks like there are still changes to the tests.

@has2k1
Copy link
Contributor Author

has2k1 commented Jul 27, 2017

Since the tests where generated with theme_void inheriting all unspecified elements from theme_grey, eliminating all the changes would require that theme_void be specified by duplicating the elements in the set them_gray_elements - theme_void_elements. I don't think that is a good idea.

I think there are two alternatives;

  1. The cop-out, decide that theme_void is should not be elaborately specified, find a sufficient level of specification and declare that the new normal.

  2. Elaborately specify theme_void then have theme_grey override (replace) elements in theme_void.

The first is what the last commit was aiming for, the 2nd though a good idea it changes the long standing status of theme_grey as the reference (fully specified) theme.

@hadley
Copy link
Member

hadley commented Jul 28, 2017

If you believe the behaviour is correct, you need to check in updated visual tests.

has2k1 added 3 commits August 1, 2017 05:38
**Issue**
At plot time, the calculation of theme elements always fell back
to the default theme. As a consequence, the default theme would
leak into complete themes where some of the elements were
unspecified.

**Solution**
Be more specific when calculating the theme defaults.

**Clean Up**
`theme_void` was insufficiently specified. The solution exposed
missing elements that had to be specified.

Fixes tidyverse#2058
Fixes tidyverse#2079
When the theme element does not exist, there should be no assigment
to any of it's attributes. There was only a single instance of this.
has2k1 added 3 commits August 1, 2017 05:38
This makes theme_void have a similar overall layout to other
themes.

And move tests to separate function.
@has2k1 has2k1 force-pushed the fix-theme-defaults branch from c454e51 to 01ecde4 Compare August 1, 2017 10:44
@has2k1
Copy link
Contributor Author

has2k1 commented Aug 1, 2017

I need some help, I cannot generate images that can pass visual tests on my system.

@lionel-
Copy link
Member

lionel- commented Aug 1, 2017

What system are you using? vdiffr is currently broken on some Linux systems, I'm investigating.

@has2k1
Copy link
Contributor Author

has2k1 commented Aug 1, 2017

Indeed, I am on a linux system.

@lionel-
Copy link
Member

lionel- commented Aug 1, 2017

Which one?

@lionel-
Copy link
Member

lionel- commented Aug 1, 2017

Also could you provide the result of running these two commands please:

gdtools::version_fontconfig()
gdtools::version_freetype()

@has2k1
Copy link
Contributor Author

has2k1 commented Aug 1, 2017

Gentoo Linux

> gdtools::version_fontconfig()
[1] ‘2.12.1’

> gdtools::version_freetype()
[1] ‘2.8.0’

@hadley
Copy link
Member

hadley commented Oct 31, 2017

@has2k1 would you be willing to update this? I can try and merge in the next week or so.

@hadley
Copy link
Member

hadley commented Nov 1, 2017

Actually, don't worry, I can do it myself

@hadley hadley closed this in 6770641 Nov 1, 2017
@lock lock bot locked as resolved and limited conversation to collaborators Jun 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants