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

Comments

Projects
None yet
4 participants
@vascotenner
Contributor

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

This comment has been minimized.

Member

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Member

jbednar commented Dec 21, 2016

I agree on all counts!

@jlstevens

This comment has been minimized.

Member

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 philippjfr added the API label Apr 10, 2017

@philippjfr

This comment has been minimized.

Member

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

This comment has been minimized.

Member

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