profile
viewpoint
Björn Steinbrink dotdash Bielefeld, Germany

dotdash/actix-extras 0

A collection of additional crates supporting the actix and actix-web frameworks.

dotdash/actix-web 0

Actix web is a small, pragmatic, and extremely fast rust web framework.

dotdash/ale 0

Check syntax in Vim asynchronously and fix files, with Language Server Protocol (LSP) support

dotdash/body-parser 0

JSON body parsing for iron

dotdash/cargo 0

The Rust package manager

dotdash/clap-rs 0

A full featured, fast Command Line Argument Parser for Rust

dotdash/docopt.rs 0

Docopt for Rust (command line argument parser).

dotdash/dotvim 0

My vim configuration

dotdash/git2-rs 0

libgit2 bindings for Rust

dotdash/gltf-viewer 0

glTF 2.0 Viewer written in Rust

issue openedfdehau/tui-rs

Single line paragraphs with a block aren't rendered

I want to realize a layout like this:

┌────────────────────────┐
│ Tabs                   │
│ Single line paragraph  │
│ List                   │
│ ...                    │
└────────────────────────┘

To Reproduce

I have constraints and widgets like this:

let constraints = [
    Constraint::Length(2),
    Constraint::Length(1),
    Constraint::Min(0),
];

let tabs = Tabs::new(/*...*/).block(Block::default().border(Border::LEFT | Border::TOP | Border::RIGHT));
let para = Paragraph::new(/*...*/).block(Block::default().border(Border::LEFT | Border::RIGHT));
let list = List::new(/*...*/).block(Block::default().border(Border::LEFT | Border::BOTTOM | Border::RIGHT));

Expected behavior Output like the example above

Actual output

┌────────────────────────┐
│ Tabs                   │

│ List                   │
│ ...                    │
└────────────────────────┘

Desktop (please complete the following information):

  • OS: Linux (Debian Sid)
  • Terminal Emulator: termite
  • Font: Input Mono 10
  • Crate version: 0.10.0
  • Backend: termion

Additional context Looking at the render function, it seems that blocks that are less than 2 units in either width or height aren't rendered at all and report an inner area of (0, 0), which looks like a bug to me as it seems fine to render a block of height 1 if the border is only on the left and right sides.

created time in 2 months

issue closedfdehau/tui-rs

Block styles override the styles of the contained element

When you try to render, for example, a Tabs widget that has a styled block, then the style of the block overrides the style of the tabs widget. This happens because in the render function, we first set the style for the whole area, and then render the block, which overwrite the style. Instead, we should first render the block, and then only set the widget's style for the inner area.

closed time in 2 months

dotdash

issue commentfdehau/tui-rs

Block styles override the styles of the contained element

Mhm, besides the Tabs example (which I worked around by adjusting my colorscheme handling to indeed only set the border style on the block), I also had a weird effect that caused artifacts in a Paragraph, which I worked around in a similar way, but I can't reproduce the original problem anymore. Closing for now, will re-open if I can reproduce the other problem again. Thanks

dotdash

comment created time in 2 months

issue openedfdehau/tui-rs

Block styles override the styles of the contained element

When you try to render, for example, a Tabs widget that has a styled block, then the style of the block overrides the style of the tabs widget. This happens because in the render function, we first set the style for the whole area, and then render the block, which overwrite the style. Instead, we should first render the block, and then only set the widget's style for the inner area.

created time in 2 months

issue openedrust-analyzer/rust-analyzer

rustflags in .cargo/config cause rebuilds when running "cargo build"

I have a .cargo/config file to make cargo use lld on x86_64 Linux.

target.x86_64-unknown-linux-gnu]
rustflags = [ "-C", "link-arg=-fuse-ld=lld" ]

This causes cargo build when run manually to behave differently from when run from rust-analyzer, thus all crates are rebuilt. This is rather annoying when I perform test runs of my binary using cargo run as it needs to rebuilt everything, and then rust-analyzer rebuilds everything again once I return to vim.

created time in 2 months

issue openedfdehau/tui-rs

Don't consume widgets when rendering them

In earlier versions it made sense to consume the widget when rendering, as many widgets only had an iterator that produced their contents, so it was gone when rendering was done. But since version 0.10, most (all?) widgets actually own their contents in a reusable way, so it would make sense to me to change the render function to take the widget by (mutable?) reference. This would allow ot reuse the widgets, avoiding the need to recreate them each render cycle, which is quite allocation heavy given the new Text/Spans/Span layout.

created time in 2 months

issue commentfdehau/tui-rs

Version 0.10: Spans can't contain line-breaks

FWIW, I just scrambled together this extension trait, which isn't quite ideal, but makes life a lot easier for me.

pub trait TextExt<'a> {
    fn append<T: Into<Cow<'a, str>>>(&mut self, s: T) -> &mut Self;
    fn append_styled<T: Into<Cow<'a, str>>>(&mut self, s: T, style: Style) -> &mut Self;
}

impl<'a> TextExt<'a> for Text<'a> {
    fn append<T: Into<Cow<'a, str>>>(&mut self, s: T) -> &mut Self {
        self.append_styled(s, Style::default())
    }

    fn append_styled<T: Into<Cow<'a, str>>>(&mut self, s: T, style: Style) -> &mut Self {
        match s.into() {
            Cow::Borrowed(s) => {
                let mut lines = s.lines();
                if let Some(last) = self.lines.last_mut() {
                    if let Some(line) = lines.next() {
                        last.0.push(Span::styled(line, style));
                    }
                }

                self.lines.extend(lines.map(|line| Spans(vec![Span::styled(line, style)])));
            }
            Cow::Owned(s) => {
                let mut lines = s.lines();
                if let Some(last) = self.lines.last_mut() {
                    if let Some(line) = lines.next() {
                        last.0.push(Span::styled(line.to_owned(), style));
                    }
                }

                self.lines.extend(lines.map(|line| Spans(vec![Span::styled(line.to_owned(), style)])));
            }
        }

        self
    }
}
TheLostLambda

comment created time in 2 months

issue commentfdehau/tui-rs

Version 0.10: Spans can't contain line-breaks

(Moved here from #341, sorry for the noise)

First off, the new Text/Spans/Span approach allowed me to remove my custom multi-line List hack, thanks for that!

Ignoring the issue of nested vectors (which IMHO needs addressing as well, but I have not though of a comprehensive solution, yet), the main point for me is that things seem to be only "half way there". Converting a &str that contains newlines to Spans´ usingFrom/Intosilently messes the result up, but directly converting it to aTexthandles the newlines just fine. But then I cannot add styling, nor can I (ergonomically) make use of that functionality if I want anything else in thatText` element.

For my use case, I guess I'd already be pretty happy with just two methods on Text, append(&str) and append_styled(&str, Style), letting me just hand over a string and optionally a style, which is then broken into Span/Spans. The implementation might be a bit tricky as you would probably need some way to track the current state with regards to whether or not an append call starts a new Spans or just adds to the current one. I'm not sure what's the best approach there.

One note on allocations: about 95% of my Spans only contain a single span, which makes me feel like that's a valid case to optimize for, i.e. avoiding the Vec in the Spans for this case. Maybe by having an enum, maybe by representing Text as a single Vec<Span> to begin with, and storing line breaks in term of offsets into that Vec.

TheLostLambda

comment created time in 2 months

pull request commentfdehau/tui-rs

Don't destroy all newlines in Spans

First off, the new Text/Spans/Span approach allowed me to remove my custom multi-line List hack, thanks for that!

Ignoring the issue of nested vectors (which IMHO needs addressing as well, but I have not though of a comprehensive solution, yet), the main point for me is that things seem to be only "half way there". Converting a &str that contains newlines to Spans´ usingFrom/Intosilently messes the result up, but directly converting it to aTexthandles the newlines just fine. But then I cannot add styling, nor can I (ergonomically) make use of that functionality if I want anything else in thatText` element.

For my use case, I guess I'd already be pretty happy with just two methods on Text, append(&str) and append_styled(&str, Style), letting me just hand over a string and optionally a style, which is then broken into Span/Spans. The implementation might be a bit tricky as you would probably need some way to track the current state with regards to whether or not an append call starts a new Spans or just adds to the current one. I'm not sure what's the best approach there.

One note on allocations: about 95% of my Spans only contain a single span, which makes me feel like that's a valid case to optimize for, i.e. avoiding the Vec in the Spans for this case. Maybe by having an enum, maybe by representing Text as a single Vec<Span> to begin with, and storing line breaks in term of offsets into that Vec.

TheLostLambda

comment created time in 2 months

more