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

Layout config discussion #1420

Open
raphCode opened this issue May 17, 2022 · 0 comments
Open

Layout config discussion #1420

raphCode opened this issue May 17, 2022 · 0 comments
Labels
discussion Conversation to figure out actionable steps. Most feature ideas start here. layout issues related to the layout system

Comments

@raphCode
Copy link
Contributor

raphCode commented May 17, 2022

The current layout system is a bit limited because it assumes hierarchical splits, whereas zellij layouts can be more flexible. This makes dumping an opened layout to file impossible in the general case.
Here we can discuss on how to improve this.

My suggestion would be to specify layouts in a little ascii art drawing, like this:

AAB
CEB
CDD
XXX
Screenshot of the layout

image

Additional information can be optionally specified afterwards:
A:
  name: "Pane #6"
E:
  focus: true
X:
  plugin: "zellij:status-bar"
  height: 2

Split sizes are inferred from the drawing by default, but can also specified by some width / height parameters.

Example:

The following layouts should be identical:

AB

A:
  width: 33%
ABB

Reasons for not deriving the sizes from the drawings alone:

  • may lead to huge drawings or imprecise ratios otherwise
    (in the case of split fractions which can't be reduced, like 7/99 lines or columns, which gets more likely at small pane sizes)
  • varying split sizes is possible without having to redraw the layout
  • fixed size panes like some plugins must be specified anyways

Advantages:

  • intuitive, easy to see what approximate layout is created at a glance
  • can still be edited with a keyboard, not requiring unicode chars
  • no potentially unnecessary information, the current approach specifies split directions for panes that are not even split
  • extremely simple config for the most common use cases (low number of equal splits)

Drawbacks:

  • splitting some panes may require a redraw of the layout (e.g. splitting A horizontally)
  • complex layouts with a mix of inferred and specified sizes may be confusing or lead to unexpected results
  • limited to 26 panes (double that if we make it case sensitive)
@a-kenji a-kenji added layout issues related to the layout system discussion Conversation to figure out actionable steps. Most feature ideas start here. labels May 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Conversation to figure out actionable steps. Most feature ideas start here. layout issues related to the layout system
Projects
None yet
Development

No branches or pull requests

2 participants