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 · 7 comments
Closed

Large layouts do not display #1026

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

Comments

@vascotenner
Copy link
Contributor

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 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

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 commented Dec 21, 2016

I agree on all counts!

@jlstevens
Copy link
Contributor

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

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

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

Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 25, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants