Skip to content
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

Large layouts do not display #1026

Closed
vascotenner opened this issue Dec 21, 2016 · 6 comments
Closed

Large layouts do not display #1026

vascotenner opened this issue Dec 21, 2016 · 6 comments
Assignees
Labels
Milestone

Comments

@vascotenner
Copy link
Contributor

@vascotenner vascotenner commented Dec 21, 2016

A larger layout is not displayed when created with hv.Layout.

Works:

a[0]+a[1]+a[2]+a[3]

Does not work:

hv.Layout(a)

But returns

:Layout
   .Overlay.Beam     :Overlay
      .Image.Beam :Image   [x,y]   (z)
      .Level.Beam :Overlay
         .Beam :NdOverlay   [Levels]
            :Contours   [x,y]   (z)
   .Diff.Differences :Image   [x,y]   (z)
   .Table.I          :Table   [Name]   (radius,error)
   .Overlay.I        :Overlay
      .Curve.I  :Curve   [y]   (z)
      .Curve.II :Curve   [y]   (z)

Current solution:

hv.Layout(a).display('all')

Proposition

always display large layouts

@jbednar
Copy link
Member

@jbednar jbednar commented Dec 21, 2016

Is there instead an option that determines how large a layout can be and still be displayed, which could be set to infinity by a user that always wants to see large layouts? That said, four items doesn't sound like a large layout.

@vascotenner
Copy link
Contributor Author

@vascotenner vascotenner commented Dec 21, 2016

It should at least give a warning that it does not display because it is to large + explanation how to show it.

Furthermore, the behaviour of +, Layout, hmap.layout should be identical.

@jbednar
Copy link
Member

@jbednar jbednar commented Dec 21, 2016

I agree on all counts!

@jlstevens
Copy link
Contributor

@jlstevens jlstevens commented Dec 21, 2016

I also agree.

I think issuing a warning and ensuring consistent behavior regardless of how the Layout is constructed is something we could fix for 1.7.

@jlstevens jlstevens added this to the v1.7.0 milestone Dec 21, 2016
@jlstevens jlstevens self-assigned this Jan 10, 2017
@philippjfr
Copy link
Member

@philippjfr philippjfr commented Apr 13, 2017

I say we throw out the max_branches option on the OutputMagic, then there's only one limit to worry about which is max_frames, which is far easier to reason about. We could consider adding a max subplots option instead but I think that should have nothing to do with a Layout in particular. Therefore my preference would be to put a deprecation warning in Layout.display and then remove the conditional in the layout_display hook. It would just be something like this:

if isinstance(layout, Layout) and len(layout.data) * nframes > max_frames:
       max_frame_warning(max_frames)
       return '<tt>'+ sanitize_HTML(layout) + '</tt>'

@philippjfr
Copy link
Member

@philippjfr philippjfr commented Apr 14, 2017

Now implemented, we no longer check the number of branches on the Layout now and the Layout.display function is deprecated.

@philippjfr philippjfr closed this Apr 14, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants