You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All the core types and functions of the Makie ecosystem are defined in Makie itself. I'd propose this package should depend only on Makie, and then the rendering can be done in any backend (GLMakie, CairoMakie, WGLMakie, or RPRMakie) of the user's choosing. This would be a breaking change, as users would be required to use using GLMakie, ProtPlot to reproduce current behavior rather than just using ProtPlot.
Thoughts? I'm happy to make this change if the maintainers are on board.
The text was updated successfully, but these errors were encountered:
This makes sense. I'm currently cleaning up and rewriting the package to improve the ribbon shapes, and to take advantage of Makie.jl recipes (#25), so I've already implemented this on the recipes branch (WIP, doesn't compile yet). Should be ready soon.😊
This has now been implemented in v0.4.0.
I'm excited about some more robust and improved visuals, and the package aligning more with how Makie is supposed to be used.
Note that the Makie recipe defines ribbon and ribbon! on its own, so the scene and camera stuff was moved to ribbon_scene for convenience. ribbon now only makes some 2D projection onto an Axis.
All the core types and functions of the Makie ecosystem are defined in Makie itself. I'd propose this package should depend only on Makie, and then the rendering can be done in any backend (GLMakie, CairoMakie, WGLMakie, or RPRMakie) of the user's choosing. This would be a breaking change, as users would be required to use
using GLMakie, ProtPlot
to reproduce current behavior rather than justusing ProtPlot
.Thoughts? I'm happy to make this change if the maintainers are on board.
The text was updated successfully, but these errors were encountered: