"Amplified" smart cells should be full width in Preview/App mode

[elepedus]

Currently, the "Amplify output" button only affects the output within the notebook itself, but doesn't persist when using the preview or deploy features.

This is a bit of a foot-gun, as it allows the user to build layouts which seem great, until they're deployed, at which point they're unceremoniously cropped e.g:

Would it be possible to persist this setting and apply it anywhere the smart cell is rendered?

[jonatanklosko]

The amplification is temporary by design, if you refresh the notebook page it is no longer applied. Technically multiple users can be using the notebook and amplification is a user-specific view adjustment, just like collapsing sections, or using one of the "views" feature.

When it comes to the app, note that the amplification takes almost full width, and width depends on the display size, so even if that was reflected in the app, it may not provide consistent experience anyway.

[hugobarauna]

@jonatanklosko, this is at least the second time I've heard a user needing a wider width inside a Livebook app.

I think this is something we can support.

I don't know the solution, though:

• configuration of the app?
• just two sizes (like Notion pages: default width and full width)
• any other solution

[jonatanklosko]

I think the canvas would solve it, once we introduce it.

[hugobarauna]

Good point.

@elepedus there's a feature we want to have. There's even an open PR for it. Here's a video of how it could work.

Do you think a solution in that direction would fulfill your need?

[rcuevas-wash]

Would like to second the need for way to escape the "notebook layout" and be able to render things horizontally.
100% of my use cases include rendering things that looks like a traditional dashboards with , many widgets presented the long way horizontally.

My current work around is to use a regular phoenix web app with live view to render horizontally, or pass custom css to something like DocRaptor to render my horizontally scrollable table, horizontally and paginated.

[elepedus]

I would settle for the ability to pass an option to a kino that toggles container constraints.

Alternatively, could the Amplify button set a value in the .livemd, which could be picked up during app/preview render to omit the max-width class?

[jonatanklosko]

Alternatively, could the Amplify button set a value in the .livemd, which could be picked up during app/preview render to omit the max-width class?

Whatever is persisted in .livemd is inherently shared across all users, and that's not desired as per the previous comment :)

An option on kino grid could be an option. Though if we go with the canvas, that's probably a more suitable solution anyway.

[hugobarauna]

@jonatanklosko, maybe we could have a solution for enabling full/configured width before having the canvas, depending on how long it will take to have the canvas.

[elepedus]

Is it worth distinguishing between amplification in the notebook view as an ephemeral user choice, and full-width smart cells (Kino Frames/Layouts) as a design decision?

I can see the argument in favour of individual notebook users choosing to amplify or not according to their screen size etc.

On the other hand, once you've build a Livebook app and deployed it to end-users who may never see the inside of a notebook, it's very useful to say "this is a full-width experience".

[jonatanklosko]

So perhaps we should have a checkbox in the app settings that makes the app full-width? @josevalim wdyt?

[josevalim]

@adiibanez if you have already started working on it, then please go ahead! I’d prioritize contributions over us tackling it! 🙇

[jonatanklosko]

We could also have it as app setting and have a custom view parameter for full width, but I can see arguments both for and against separating those. I am fine with a notebook setting that applies all around.

I don't think we have a place for such setting right now, we can add a notebook settings modal available from the notebook menu.

[adiibanez]

@josevalim @jonatanklosko I'll share my livebook fork covering a MVP implementation of :default / :fullscreen layout in app_session_live.ex. Most probably a few rounds of feedback / advice will be required.

[adiibanez]

This is the current WIP state of my attempt at enabling a fullscreen app layout.

https://github.com/adiibanez/livebook/tree/fullscreen-app-layout

main...adiibanez:livebook:fullscreen-app-layout

Pls have a look and let me know if such an implementation would be acceptable.

Current open issues:

• layout setting is valid for a session but is not persisted in the livemd file. any hints about where in the code the settings get serialized into the livemd file?
• z-index layout issues for menu vs output text vs Kino.JS.Live components. Any hints on the concept of z-index "layers" in livebook or how to control z-index of different components / output cells would be very much appreciated.

Questions:

• How can I ensure that settings are persisted in the livemd file? Currently only following settings are persisted:

livebook:{"app_settings":{"access_type":"public","auto_shutdown_ms":5000,"slug":"badiculture"}} 

[jonatanklosko]

@adiibanez based on the conversion above, the attribute should be a part of %Notebook{}, rather than %AppSettings{}, since it will apply to notebooks and apps. For persistence you can look at other attributes, such as autosave_interval_s, specifically the import/export modules.

z-index layout issues for menu vs output text vs Kino.JS.Live components

A specific example with a screenshot would help to understand the issue :)