Text wrapping too late #2578

mikedilger · 2023-01-12T23:11:01Z

Describe the bug

Under certain conditions, text wrapping leaves one line of text too wide compared to the container, in my case pushing the container width (or it's ancestors) beyond the bounds of the window.

Tested on master, 60b4f5e

To Reproduce

Steps to reproduce the behavior:

Within an area that is not as wide as the window...
Horizontally wrapped...
Render a short link, and then a very long string of characters with no space to natrually break them on.
The first line of that very long string of characters will be too long, but subsequent lines won't.

Expected behavior

Wrapping that doesn't expand the width of the container.

Screenshots

https://user-images.githubusercontent.com/1653275/212086814-c878a200-f7ab-4a84-a5f0-a0b89ec740a5.png

Normally subsequent posts (below the horizontal lines) line up on the left edge. Here, they are pushed left beyond the edge of the window.

Desktop (please complete the following information):

OS: ArchLinux (X11/winit)
Browser: n/a
Version: eframe 0.20.1

The text was updated successfully, but these errors were encountered:

emilk · 2023-02-08T09:48:14Z

A simple reproduce would help a lot, preferably just a call to text_layout::layout

mikedilger · 2023-02-18T23:14:53Z

Ok I did some digging and this reproduces it

main.rs:

use eframe::egui;

fn main() {
    let native_options = eframe::NativeOptions::default();
    eframe::run_native("My egui App", native_options, Box::new(|cc| Box::new(MyEguiApp::new(cc))));
}

#[derive(Default)]
struct MyEguiApp {}

impl MyEguiApp {
    fn new(cc: &eframe::CreationContext<'_>) -> Self {
        Self::default()
    }
}

impl eframe::App for MyEguiApp {
   fn update(&mut self, ctx: &egui::Context, frame: &mut eframe::Frame) {
       egui::CentralPanel::default().show(ctx, |ui| {
           ui.horizontal_wrapped(|ui| {
               ui.hyperlink_to("@npub1vdaeclr2mnntmyw...", "whocares");
               ui.label(" lnbc10u1p3lz4dppp5dsj2mh5kgqfqqxwhkrkw60stn8aph4gm2h2053xvwvvlvjm3q9eqdpqxycrqvpqd3hhgar9wfujqarfvd4k2arncqzpgxqzz6sp5vfenc5l4uafsky0w069zs329edf608ggpjjveguwxfl3xlswg5vq9qyyssqj46d5x3gsnljffm79eqwszk4mk47lkxywdp8mxum7un3qm0ztwj9jf46cm4lw2un9hk4gttgtjdrk29h27xu4e3ume20sqsna8q7xwspqqkwq7");
           });
       });
   }
}

- `row_start_x` tracks a virtual position in the source paragraph (the one that is too long) for which length has already been processed. When creating an empty row, this position should not be updated as no glyphs were consumed from the source paragraph. - added example that would demonstrate the problem if the line was included, and that is fixed with this commit

bu5hm4nn · 2023-03-08T05:03:45Z

Should be fixed in #2791. Read description of PR for explanation why that line shouldn't be there.

- `row_start_x` tracks a virtual position in the source paragraph (the one that is too long) for which length has already been processed. When creating an empty row, this position should not be updated as no glyphs were consumed from the source paragraph. - added example that would demonstrate the problem if the line was included, and that is fixed with this commit

Fix issue emilk#2578

There was confusion in the code over how to break when on a non-empty visual row (`first_row_indentation > 0.0`), causing text to be shifted left outside the ui frame. This is the case for example when another label has already been placed in this `ui.horizontal_wrapped()`. This fix will not create an empty row, essentially starting a newline, but rather try to fit as much text as possible on the existing row. IMO this is the desired use of a wrapping layout. I've also added an example that would demonstrate the problem if the line was included, and that is fixed with this commit

Fix issue emilk#2578 (again)