-
-
Notifications
You must be signed in to change notification settings - Fork 356
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Auto-layout mode that prevents plots from shrinking beyond readability #4234
base: master
Are you sure you want to change the base?
Conversation
Currently has a bias for taller over wider, but I can change that. |
Codecov Report
@@ 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
Continue to review full report at Codecov.
|
@@ -434,6 +434,7 @@ const _plot_defaults = KW( | |||
:thickness_scaling => 1, | |||
:display_type => :auto, | |||
:warn_on_unsupported => true, | |||
:plotarea => :auto, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already have a notion for plotarea with a slightly different meaning
Line 39 in 6266ff8
plotarea::BoundingBox # the part where the data goes |
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah hmm. What would you recommend?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
size
if the total size needed is larger than the set size.Current:
This PR: