Adjust compat settings and progress named argument

[dmbates]

• Replace resolution named argument with size in Makie calls. Restrict version of Makie to later versions with the size named argument.
• Bump allowed versions of BSplineKit
• Use progress named argument in call to parametricbootstrap.

We may want to wait for a new release of CairoMakie before incorporating these changes. There are warnings in the tests that trace back to CairoMakie.

[palday]

can you also bump the version so that we can immediately tag a release?

[dmbates]

I believe the version has already been bumped to 0.3.28 (last release was 0.3.27). Am I confused?

[palday]

coefplot! now seems to use the first theme color (blue) instead of black, which is fine on its own but looks weird overlain on the ridgeplot!. Can you add an explicit color=:black to the coefplot! call within ridgeplot!?

[dmbates]

I have added color=:black in the call to coefplot! as you requested.

[palday]

@dmbates It seems like there is a bigger problem with recipes in Makie 0.20:

MakieOrg/Makie.jl#3514

I'm going to delay merging this until we get some triage over there. If it looks like recipes are just generally deprecated, I'll rework the implementation to not rely on them.

[dmbates]

@palday Thanks for checking on that.

[dmbates]

@palday Is there something I can do to help get this PR in shape to commit?

We seem to be in a convoluted dependency situation w.r.t EmbraceUncertainty. We can't use julia v1.10.0 to render that project unless we allow AlgebraOfGraphics v0.6.18, which includes a fix for the dictionaries issue when using density(). But that will require later versions of Makie than MixedModelsMakie currently allows.

I am willing to devote time to this, including rewriting the density plots in EmbraceUncertainty to avoid AlgebraOfGraphics (I am starting to agree with you that it is easier in the long run to call Makie functions directory and avoid AoG), if you can give me guidance on how to proceed.

[palday]

The coef- and ridgeplots are broken because of the issue I linked above, but I think that's an upstream issue. I can start working on a replacement that doesn't rely on recipes, but there's no reason to block this work on that.