Light-dependency recipes, complex recipes with layouts and axis access, and Layoutable recipes

[jkrumbiegel]

MakieCore already only depends on Observables. All other dependencies seem not strictly necessary to support plot recipes. The story could be a bit different with layouts, as GridLayoutBase carries a couple dependencies of its own, for example GeometryBasics.

Currently, each plotting function defined with @recipe has its own function type, which is also embedded in the Combined parametric type, which makes up the actual plot type. This means that to use any of the plots defined in Makie.jl (not MakieCore) one would currently have to using Makie to get access to these plot types.

One option would be to make plot(:Violin, args... or plot(Val(:Violin), args... equivalent to violin(args... so that packages who want to offer Makie recipes can use the necessary plotting functions through these Symbols.

Recipe axis access

A missing feature is axis access for recipes, or at least the ability to set default axis properties from a recipe. Because the real Axis, Axis3 etc types are quite heavy, it's not feasible to put them into the recipe system. But it should at least be possible to allow recipes to set certain axis attributes. For that, again the mere reference to, e.g., :Axis by Symbol could be enough.

At what point in the pipeline should the axis keywords be generated? Currently, the axis is always created before a plot object is instantiated, which is then plotted directly into the new axis. But recipes will probably want to put the code for the plot and the code for computing axis keywords close together, as the information going into the plot will also overlap with the information styling the axis. It's not entirely clear where that logic should go, as it seems impractical to return both a plot object and axis attributes (and also figure attributes, if we're at it) from a plot! method. Maybe an empty axis keyword dictionary could be passed to the plot! method, which it could then populate if it wants to. That would leave the return type as just the plot object.

Maybe a function like get_axis_attributes(plottype, axistype, args...; kwargs...) would be cleaner, which would be called before the actual plot! method, and before the axis has been created. But this would again have the problem of being separate from the direct plotting logic, which could lead to code duplication when extracting information from input arguments etc. This could also handle the different keywords for different axis types better, in case a plot method wants to set different labels for Axis and Axis3, for example.

...

more on the other topics later

[jkrumbiegel]

Block idea

The Layoutable type could go away and be replaced by Block. A block could be:

• any of the current Layoutables
• SliderGrid instead of the loose collection of stuff in labelslidergrid!
• Any complex plot recipe with legends, colorbars, multiple axes, etc

Created by macro, each type would have:

• a Scene
• a GridLayout
• a parent (nothing, Figure, scene?)
• a list of attributes which are normal Observables with special access semantics

A definition could look like this:

@Block Axis begin
    # default fields such as scene and layout inserted automatically
    @attributes begin
        "the x label"
        xlabel::String = ""
        "the background color"
        backgroundcolor::RGBAf0 = :white
    end
end

Two constructors, Axis() would create its own Figure and return FigureBlock(figure, axis), and Axis!(f[1, 1]) would put the axis into the existing Figure.

The attributes in the @attributes block carry documentation and defaults with them and are rewritten to fields with Observable{Type} type, where Observable doesn't have to be spelled out and missing type means Observable{Any}.

Attributes should also be inheritable from theme entries, something like fontsize = inherit(:fontsize, 10) or equivalent.

[jkrumbiegel]

Here's another idea. The problem with the previous approach was that Scene is not aware of Blocks, so there's duplication in data storage between Scene (stores the block's plots) and Figure (stores the Block) and it's not easy to remove a Block (need to keep track of what was put into the parent scene). Also, it's too much overhead to have each Block have a Scene. Here's a revised list of features I would like to have:

AbstractBlock

• can be added to a Scene like an AbstractPlot
• can be removed with all children in one delete! operation
• can have
  • child scenes
    • like Axis's plot area
  • child AbstractBlocks
    • like Sliders in a LabelSliderGrid
  • child AbstractPlots
    • these belong to the parent Scene (like the decorations in Axis)
• can be added to a GridLayout, so has a layoutobservables field etc.
• if instantiated by itself, creates its own parent Figure and returns a FigureBlock or something like that (analogous to FigureAxisPlot for the plotting operations), opening a window or showing a plot if returned in a correct context
• A Figure could keep track of a vector of AbstractBlocks, or let the underlying Scene handle that to not duplicate the information (right now the duplication exists because Scene doesn't handle Blocks)

[aplavin]

I wonder if this discussion went anywhere after what's visible in the current thread... This would be a very useful piece of functionality, and the design proposed by @jkrumbiegel in the first post does seem very reasonable:

Maybe a function like get_axis_attributes(plottype, axistype, args...; kwargs...) would be cleaner, which would be called before the actual plot! method, and before the axis has been created.

I played with a helper macro that is used this way:

Makie.convert_arguments(::Type{Scatter}, x::MyType) = ... regular convert_arguments stuff ...
MakieExtra.@define_plotfunc scatter MyType
MakieExtra.default_axis_attributes(::Type{Scatter}, x::MyType) = (; xlabel=..., ylabel=..., aspect=...)

scatter(MyType())  # creates axis with the attributes from default_axis_attributes()
scatter!(ax, MyType())  # just plots the data without any axis modifications

and find this quite useful already.
The implementation is at https://github.com/JuliaAPlavin/MakieExtra.jl/blob/master/src/helpers.jl#L1-L34 and simply defines plot(x) and plot(position, x) functions that create Axis with those attributes.

Would be best if there was such a get_axis_attributes or default_axis_attributes function defined in Makie! It would be called by all of plot(x), plot(position, x) and probably also plot!(ax, x) if this is the first plot made on ax.
Also, it should work with SpecApi, and this part does require the function being a part of Makie proper. Would be quite natural if S.Axis([plots=[S.Scatter(mytype), S.Scatter(othertype)]) used default_axis_attributes from the first plot on axis.

What do you think of this design?