Skip to content

Conversation

@gustaphe
Copy link
Collaborator

There are some keyword arguments which it makes sense to interpret as "on a data axis" - meaning that it would be useful to query the recipe pipeline for how to interpret user provided types.

Some such arguments that I have identified are

  • lims
  • ticks
  • annotation coordinates
  • ribbon/error/fillto
  • marker_z and friends
  • colorbar lims and ticks
  • marker_size (this one is questionable)

So far, a number of these have been hardcoded for Unitful and Dates, which are two of the most obvious use cases, but if a user wanted to be able to set limits in their own data type they would have to either override unexported Plots functions or handle the conversion to Tuple{Float, Float} themselves. With this PR, a type recipe is enough.

@gustaphe gustaphe added the extension new behaviour label Oct 12, 2022
src/axes.jl Outdated
function attr!(axis::Axis, args...; kw...)
# first process args
plotattributes = axis.plotattributes
dummy_attributes = Dict{Symbol, Any}(:plot_object=>first(axis.sps).plt)
Copy link
Member

Choose a reason for hiding this comment

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

What are those needed for?

Copy link
Collaborator Author

@gustaphe gustaphe Oct 12, 2022

Choose a reason for hiding this comment

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

Good question. RecipesPipeline._apply_type_recipe has

function _apply_type_recipe(plotattributes, v, letter)
plt = plotattributes[:plot_object]
preprocess_axis_args!(plt, plotattributes, letter)
rdvec = RecipesBase.apply_recipe(plotattributes, typeof(v), v)
warn_on_recipe_aliases!(plotattributes[:plot_object], plotattributes, :type, v)
postprocess_axis_args!(plt, plotattributes, letter)
return rdvec[1].args[1]
end

where it asks the first argument for :plot_object, which it then uses for pre- and postprocessing. Perhaps the function should instead be extended to accept an Axis object instead or something, this just seemed like the minimum intrusion operation to me.

@codecov
Copy link

codecov bot commented Oct 12, 2022

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.88%. Comparing base (e9fb3b3) to head (2c90439).
⚠️ Report is 455 commits behind head on master.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #4453      +/-   ##
==========================================
- Coverage   80.60%   79.88%   -0.73%     
==========================================
  Files          30       40      +10     
  Lines        7466     8196     +730     
==========================================
+ Hits         6018     6547     +529     
- Misses       1448     1649     +201     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@Ickaser
Copy link
Contributor

Ickaser commented May 26, 2025

Has Plots moved far enough towards 2.0 that it would be difficult to revive this PR? Time is limited as always but this seems like a functionality related to eventually solving #4741, which would be useful to me, so I would be willing to make some efforts here

@BeastyBlacksmith
Copy link
Member

I don't think any of the relevant portions of the code have changed, so it shouldn't be hard to port the PR.
It's not yet completely clear to me, what the implications of doing this are though.

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

Labels

extension new behaviour

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants