Track in all geoms the changes in 'ggplot2' 4.0.0

[aphalo]

See pull request in ggplot2 repo.

The approach curently in use in geom_label_s() in conceptually similar but with a different user interface than in geom_label(). This is logical for geom_label() as the default behaviour had to be the same as earlier and fit in with the new theming of geometries.

However, the approach used in geom_label() does not scale up well to more complex grobs like those in geom_table(), and consistency within 'ggpp' is very important.

Adding forward compatibility with geom_label() to label geometries from 'ggpp' is a possibility, but would add complexity to the user interface.

• [x] Document differences

[aphalo]

• [x] Change default linewidth in 'ggpp' to match that in 'ggplot2' 4.0.0. Achieved by use of from_theme()
• [x] check consistency of already implemented support for linewidth with the one added in 'ggplot2' 4.0.0. Default changed to the thinner line used now in 'ggplot2' 4.0.0.
• [x] replace use of parameter segment.linewidth by aesthetic linewidth in geom_text_pairwise() Not changed for consistency with geom_label_pairwise().
• [x] replace use of parameter segment.linewidth by aesthetic linewidth in geom_label_pairwise() Not changed as aesthtic linewidth is in use for box border. Better keep this consistent.
• [x] consider if the new colour-targetting mechanism use for geom_label() in 'ggplot2' 4.0.0 can replace the one already in use in 'ggpp'? or be supported in parallel not to break existing code? I will keep the current mechanism.
• [x] update the box padding computations in geom_label_s(), geom_label_pairwise() and geom_label_npc() to match that used in geom_label() in 'ggplot2' 4.0.1.

Implement support for default geom aesthetics extracted from theme element geom

• [x] Implement fallback for from_theme() for 'ggplot2' < 4.0.0
• [x] ggpp::geom_text_s()
• [x] ggpp::geom_text_npc()
• [x] ggpp::geom_label_s()
• [x] ggpp::geom_label_npc()
• [x] ggpp::geom_point_s()
• [x] ggpp::geom_table()
• [x] ggpp::geom_table_npc()
• [x] ggpp::geom_plot()
• [x] ggpp::geom_plot_npc()
• [x] ggpp::geom_grob()
• [x] ggpp::geom_grob_npc()
• [x] ggpp::geom_x_margin_arrow()
• [x] ggpp::geom_y_margin_arrow()
• [x] ggpp::geom_x_margin_point()
• [x] ggpp::geom_y_margin_point()
• [x] ggpp::geom_x_margin_grob()
• [x] ggpp::geom_y_margin_grob()
• [x] ggpp::geom_quadrant_lines()
• [x] ggpp::geom_vhlines()
• [x] geom_text_pairwise()
• [x] geom_label_pairwise()

Implement a better way of overriding/combining the plot theme with the table theme.

• [ ] ggpp::geom_table()
• [ ] ggpp::geom_table_npc()

[aphalo]

@danielinteractive Hi Daniel. I am working on an update to 'ggpp'. I have added support for the geom theme element that was added to 'ggplot2' >= 4.0.0 and I still aim to see if I can also catch up with the new features in the position functions from 'ggplot2' >= 4.0.0. I intend not to make 'ggplot2' >= 4.0.0 a requirement. So my question is how far back support for earlier 'ggplot2' versions is the minimum required for your package? e.g., is >= 3.5.0 enough? I intend not to submit a new version immediately to CRAN, maybe in a month or so, depending on my progress. At the moment, this update is in a separate branch named ggplot.4. I will merge this branch into master earlier and it will then be available through R-Universe, so, please, let me know how are you dealing with the 'ggplot2' 4.0.0 update downstream of 'ggpp'. Best wishes.

[danielinteractive]

Hi @aphalo , thanks for reaching out. I just checked and currently ggplot2.utils requires ggplot2 (≥ 3.3.0). But I think it would be perfectly fine for your package to require ggplot2 (≥ 3.5.0). I would be happy to test the package with your updated package version branch once ready, but I don't foresee any problems.

[aphalo]

Hi @danielinteractive , currently the check action here in GitHub is failing because some snaps files are missing. All unit tests and checks are good locally. There is a problem with the git repo, I am not sure what, yet. The missing snaps are in my local repo but not in GitHub. I see locally some dangling blobs and dangling commits. The difference between origin and local is not "seen" and I also see problems with staging any new changes when they are detected. (I am using GitKraken.)

[aphalo]

Hi @danielinteractive , git problem solved. It was simpler than I expected. It seems that either 'usethis' or GitKraken had added tests to .gitignore. The dangling blobs and dangling commits were, I guess, just normal git behaviour.