Add vertical splits

[dankilman]

Not sure how the API for this should look like, but might be useful

[conradludgate]

I've been thinking about this. Currently (as far as I'm aware), a viewer owns a set of boxes, and each box has it's box height.

Instead, what if a Viewer has a Layout object, which owns the boxes. This layout then has the column/row widths/heights.

When a box has an update, it forwards the update to the layout parent, which works out which row the update occurred, then updates the entire row of boxes accordingly.

Layouts can be customised quite simply. (similar to grid-template-areas in CSS)

• 1 2/3 3 could define a layout with two panes on top and 1 full width pane on the bottom.
• 1 2/1 3 can define a layout with 1 full height pane on the left and 2 panes on the right.

We can have a set of predefined layouts, as well as allowing them to be specified as environment/argument parameters.

I'm interested in implementing this, although I would like feedback before I dive into it.

[dankilman]

Thanks for showing interest :)
I have many thoughts about this and will reply once i find time to do so :)

[dankilman]

These are a few thoughts I had when contemplating this feature:

• There is currently a notion of collapse which is toggled using c. How should a row with more than 1 box behave when collapsing?
  collapse the entire row? perhaps collapse the focused box and expand the non collapsed boxes on the same row? not sure, these are just thoughts.
• How will layout be defined in cases where boxes are added dynamically after the viewer started? How will this be reflected in the python API?
• I'm wondering what is your use case? For me (and perhaps for you as well) this just seems like a very fun feature to implement, but it will surely increase the complexity greatly (and the code is already quite complex in certain places). So I'm wondering whether it makes sense to add this complexity for a relatively niche use case.
• Changing the width of a box dynamically, while preserving the wrapped/unwrapped mapping will not be trivial.
  I'm not sure if this is something we'd like to enable without giving it the attention it deserves.

To sum it up, there will be many places (some big, some small) that will not be trivially easy to integrate with the addition
of vertical splits. So perhaps a more conservative approach should be attempted first, where vertical splits are static in nature?

This is all just me brainstorming, so take what I say with a grain of salt.

[conradludgate]

How should a row with more than 1 box behave when collapsing?
collapse the entire row? perhaps collapse the focused box and expand the non collapsed boxes on the same row? not sure, these are just thoughts.

I had similar thoughts. I wasn't sure what the best approach would be either. Collapsing a single box doesn't make sense since it won't change the view, unless it disappeared and the other boxes in the layout moved up to fill it's position. Otherwise you could change collapse to work on rows/columns, but that's also not ideal.

How will layout be defined in cases where boxes are added dynamically after the viewer started? How will this be reflected in the python API?

The layout could be repeating vertically by default, so a layout of 1 2 could be the standard, and if a third box were to be added, it would become a layout 1 2/3 4, if that makes sense? It just infinitely scales downwards, like it works currently. Not sure if there's much that needs to be changed in the API to support this.

I'm wondering what is your use case? For me (and perhaps for you as well) this just seems like a very fun feature to implement, but it will surely increase the complexity greatly (and the code is already quite complex in certain places). So I'm wondering whether it makes sense to add this complexity for a relatively niche use case.

I left this comment when you posted this project on HN. I was hoping it to become my standard docker-compose logs viewer. I hate the current docker-compose logs output where it collects all of the services' logs into a single flow, prefixed with the service name. It's just difficult to read. This project makes it easy to turn into multiple different panes to view separately but still collectively. See this script - Although the fact that each box takes up a whole row and has very low depth when you have 5+ services makes it almost useless since each box in my screen has about 7 lines. If it could support 2x2 boxes per screen, then just scrolling more boxes vertically, it would be perfect for me.

Changing the width of a box dynamically, while preserving the wrapped/unwrapped mapping will not be trivial.
I'm not sure if this is something we'd like to enable without giving it the attention it deserves.

I agree, that is a difficult problem to solve - although not impossible. It's something text editors can do quite quickly, but still it won't be trivial.

Thanks for your thoughts

[dankilman]

The repeating option sounds like the way to go.
I would keep the default as it is (as from your previous comment I seemed to understand you want to make it 2 boxes per layout row as default)
Regarding collapse I think it should be either disabled when layout contains more than 1 box in a row, or it should apply to the entire row. not sure how intuitive this is though.

If you end up working on this, the most fragile part would be terminal resize handling. The matrix of variations that should be verified is wrapped/unwrapped and buffer limit/no buffer limit.
If you'd like to add dynamic box width change (similar to dynamic box height that currently exists), then this should be properly QA'd as well I suppose.

Anyway, interesting feature indeed. I'm all for you pursuing it :)