Open jariji opened 2 weeks ago
Yeah, unfortunately these are due to current Makie restrictions. The "SpecApi" interface used here (and in packages like AoG or tidier) is experimental, and specifically passing plot attributes or axis attributes doesn't always work reliably. The situation is improving on the Makie side, related bugs get closed over time.
Of course, these things aren't intended to be in the final FPlot api!
Allowing recipes to change axis attributes is a long-standing Makie issue, I wouldn't really be on that getting resolved any time soon...
Some pragmatic solution is needed for the meantime. I also dislike _axis
and doaxis
, and the current approach
https://github.com/JuliaAPlavin/MakieExtra.jl/blob/00000000a40dc2bf327e1b4f1c5b6abf468d4f06/src/fplot.jl#L60-L61
(using GridLayout + Axis) is susceptible to issues when FPlot is an observable.
An alternative would be to define axplot()
function and require axplot(scatter, fig[1,1], FPlot(...))
instead of scatter(fig[1,1], FPlot(...))
for it to set axis labels (and more attributes in the future). Any other ideas @jariji?
An alternative would be to define axplot() function and require axplot(scatter, fig[1,1], FPlot(...)) instead of scatter(fig[1,1], FPlot(...))
That's getting a bit heavy. Also I've been imagining the constant attributes like color=:red
go in scatter(;...)
whereas FPlot(;...)
is supposed to take callable kwargs (not constants).
Also I've been imagining the constant attributes like color=:red go in scatter(;...) whereas FPlot(;...) is supposed to take callable kwargs (not constants).
Sure, it does, no question on that! How is that related here?
I guess you mean axplot(scatter, fig[1,1], FPlot(...); color=:red)
, then I withdraw that part of my comment.
Sure, kwargs are propagated, and going to be propagated! The only issue currently is with axis attributes, it's very hard and poorly supported in Makie for FPlot(...)
to set stuff like labels and scales when plotting with regular plotting functions.
Variants:
scatter(fig[1,1], FPlot(data, (@o _.a), (@o _.b), color=(@o _.c)), markersize=5)
– ideal, but impossible for nowscatter(fig[1,1], FPlot(data, (@o _.a), (@o _.b), color=(@o _.c)), markersize=5, doaxis=true)
– current, has internal issuesaxplot(scatter, fig[1,1], FPlot(data, (@o _.a), (@o _.b), color=(@o _.c)), markersize=5)
– axplot gets all these arguments directlyaxplot(scatter)(fig[1,1], FPlot(data, (@o _.a), (@o _.b), color=(@o _.c)), markersize=5)
– just use axplot(scatter)
instead of scatter
, more straightforward modificationA(scatter)(fig[1,1], FPlot(data, (@o _.a), (@o _.b), color=(@o _.c)), markersize=5)
– shorter name, like A
/F
/...I think I like 4 or 5 the most... Thoughts?
Btw, these functions can support argument widgets=[...]
in the future for interactive widgets, like drawing FPlot-aware selections.
Tbh I haven't been using the scatter(fig[1,1], ...)
form. I normally use scatter(x,y)
or scatter!(ax, x, y)
.
What's the benefit of the curried forms in 4 and 5 relative to 3?
scatter(x,y)
Indeed, it should also be supported – trivial, just create Axis(Figure()[1,1])
if fig[...]
not passed.
scatter!(ax, x, y)
This probably shouldn't change axis attributes in any way, because it plots into an existing axes. So, no wrapper needed!
What's the benefit of the curried forms in 4 and 5 relative to 3?
Potentially more understandable and easier to switch from 1 to them: just replace scatter
with axplot(scatter)
, nothing else.
What's going on with
_axis
anddoaxis
? My first reaction is they're aesthetically unappealing and they hint that something untoward might be happening underneath.