Tabs: Remove initial space prior to Tabs widget and around tab dividers inside

[joshka]

Problem

The Tabs widget creates a non configurable space prior to the beginning of the tab, and non removable spaces between the tab text and the divider. E.g. in the following, the space prior to "Inbox" and two of the spaces between "Inbox" and "Sent" are non-removable.

Tabs::new(vec![" Inbox ", " Sent ", " Drafts "])
    .style(Style::new().fg(Color::Indexed(244)).bg(Color::Indexed(232)))
    .highlight_style(
        Style::new()
            .bold()
            .fg(Color::Indexed(232))
            .bg(Color::Rgb(64, 96, 192)),
    )
    .select(0)
    .divider("")
    .render(area[0], buf);

Both of these spaces can be got to by alternative means (rendering to an area with a margin, or changing the divider to include spaces either side of the divider)

Solution

• Remove the initial space
• Change the default divider to " │ " from "│" and remove the excess spaces

This breaks rendering in two places:

• Apps that want the extra initial space can fix this by putting a margin around the tabs. E.g.: let area = area.inner(&Margin::(new(1,0)));
• Apps that use a custom divider can fix this by adding spaces either side of the divider. E.g.: .divider(" • ")

Alternatives

1. Make the amount of extra space a configuration option with the default set to the current amount
2. Make the extra space characters configurable with the default option set to a space

I think the main solution is probably reasonable - but so are the alternatives that don't break existing code, so I'd like to get consensus before implementing this.

Additional context

[bhavuk2002]

i can do that, assign me

[joshka]

Hey there - I'd like us wait a little bit for some feedback from users before we jump to PRs on this:

I think the main solution is probably reasonable - but so are the alternatives that don't break existing code, so I'd like to get consensus before implementing this.

[bhavuk2002]

okay, what can i do i the mean while? as you have changed the title, i have done the same in my PR. can you suggest some good first issue on which i can work on? or for this issue i can do something?

[joshka]

I just did a quick pass through the issues and I don't think there's a huge amount of good first issue stuff to do. Most of the current issues require a bit more research / discussion before implementing. The obvious one that might be worth looking at are documentation tasks (which require spending some time with each doc topic and assessing it. See:

• Docs: improve general methods documentation #386 (and note the checklist)

I'll see if I can get a few more good first issue friendly issues written up.

[joshka]

The impact of making a change to the way Tabs render would be that any end users using apps built with Ratatui would see the change (especially if they install the app via cargo install without --locked). This means breaking rendering here breaks Ratatui's user's users.

To move this issue towards a solution, we should document in this issue some basic rendering of tabs and note how each approach would change that. E.g.:

Approach 1:

• Small description of changes to code
• The following existing code (one or more examples):

  example tab render

  Renders as: Tab1 | Tab2 | Tab3
• With the change this renders as: Tab1 | Tab2 | Tab3
• To make the rendering the same as it was previously the app code would have to change to:

  example changed

Approach 2:

• ...
• With the change, code that needs to remove the divider / spaces would instead do:

  example of how to use the code
  

etc.

@bhavuk2002 does that sound like something that you could do?

[bhavuk2002]

Uhm... somewhat im getting it but approaches are unclear i guess have implemented chanes that way already ? Am i right?

[joshka]

Assuming a buffer with:

01234567890123456789012
abc                 xyz

Approach 1 is from the Solution section. It removes the initial space before the tabs and changes the default divider to " | "
So the sample code:

Tabs::new(vec!["123","456","789"]).render(area, buf);

renders:

01234567890123456789012
abc 123 | 456 | 789 xyz

And

Tabs::new(vec!["123","456","789"]).divider("x").render(area, buf);

renders:

01234567890123456789012
abc 123 x 456 x 789 xyz

Changing things for approach 1 changes the renders of those two code to:

01234567890123456789012
abc123 | 456 | 789  xyz

01234567890123456789012
abc123x456x789      xyz

• "123x456x789"
  To fix these errors, the code examples would have to be updated to...

Approach 2

• I'm unsure what the methods should look like, but perhaps:

  Tabs::new(vec!["123","456","789"])
    .initial_indent(1)
    .divider_padding(1) // or perhaps (left, right)?
    .render(area, buf);

  I'd expect that the examples above would render the same as they started

Approach 3

• I'm unsure what the methods should look like, but perhaps:

  Tabs::new(vec!["123","456","789"])
    .initial_prefix(" ")
    .divider_padding(" ")
    .render(area, buf);

  again, the examples above don't change the rendering

I'm not sure if the names of the functions make sense - consider how these would look in docs etc. Consider what would be the natural names for this feature. etc. Think about some of the choices and find some way to justify one vs another.

[bhavuk2002]

okay im on it

[Valentin271]

This seems to be fixed in #629, closing. Feel free to reopen if I'm wrong.