Auto-layout mode that prevents plots from shrinking beyond readability#4234
Auto-layout mode that prevents plots from shrinking beyond readability#4234BioTurboNick wants to merge 1 commit intoJuliaPlots:masterfrom
Conversation
|
Currently has a bias for taller over wider, but I can change that. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #4234 +/- ##
==========================================
- Coverage 77.93% 77.58% -0.35%
==========================================
Files 28 28
Lines 7101 7134 +33
==========================================
+ Hits 5534 5535 +1
- Misses 1567 1599 +32 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| :thickness_scaling => 1, | ||
| :display_type => :auto, | ||
| :warn_on_unsupported => true, | ||
| :plotarea => :auto, |
There was a problem hiding this comment.
We already have a notion for plotarea with a slightly different meaning
Line 39 in 6266ff8
IIIUC, your plotarea is the whole area covered by one subplot, whereas the subplot field is the area of the axes and data without labels and margins and stuff
There was a problem hiding this comment.
Ah hmm. What would you recommend?
There was a problem hiding this comment.
call it subplotarea would be one option. This would also need an entry in arg_desc.jl
|
In general this is a different thing, than I had in mind with |
|
Hmm ok. Two of my pain points I'd like to resolve is being able to specify rows/columns for a grid without having to provide an exact number of plots to fill it, and prioritizing visibility of many plots over a fixed overall plot area. How can this fit in with what you have in mind, so that they don't conflict? |
can you give an example of how you would use it, if it where implemented? What I don't like here is that the plot size changes without the user explicitly requesting it.
Then you could have an automatic layout that changes plot size with |
I'm building Pluto notebooks for our analysis pipeline, and there can be a variable number of samples per experiment. I may know that I can comfortably fit 3 plots across but otherwise don't care how many rows it takes. Or vice versa for columns. A more specific example might be a linear trace for each event. They can get pretty short and still be legible because the length matters more. |
I meant in terms of function calls. |
Ah, yes. Maybe Maybe we would also want a Maybe |
|
This won't be breaking would it ? |
|
I think perhaps this might be better considered as part of a revamped layout system for 2.0 than to solve here. |
This is a first pass that probably doesn't account for everything needed.
However, what it does is it simply computes a row and column count, the widths and sizes of them, passes the work down to the normal layout method, then the calling plot code reads the height and width attributes from the layout and overrides
sizeif the total size needed is larger than the set size.Current:

This PR:
