Improves the Atom alignment in TextEdit

[RndUsr123]

• Closes Regression: #7587 breaks TextEdit.horizontal_align() #7999
• I have followed the instructions in the PR template

This seems to work in most scenarios but there's 2 things I'm not fully sure about:

1. When only a prefix or suffix is used, horizontally-centered text is not really centered. This doesn't always look great but ensures all the available space is used so I'm not sure what the best approach here is.
2. Since atoms can't currently be vertically aligned, hint text and prefix/suffix might jump down after some text is entered when vertical_align other than Align::TOP is used. There's possible workarounds, but this might work for the time being if vertical alignment support in atoms is planned for the near future

Screenshots:

[github-actions]

Preview available at https://egui-pr-preview.github.io/pr/8022-TextEdit-Atoms-Alignment
Note that it might take a couple seconds for the update to show up after the preview_build workflow has completed.

View snapshot changes at kitdiff

[emilk]

This existing snapshot tests doesn't seem to cover this fix?

[RndUsr123]

Not sure. Might it be because the current snapshot test is based on the current commit, which uses left-alignment regardless of what .horizontal_align is set to?

The compiled demo definitely looks correct visually and I'm getting no error on my machine after refreshing the snapshots...

Edit: indeed, there's something wrong. I've run all tests on my machine and got a STATUS_ACCESS_VIOLATION error on different tests at different times. Thing is, it also happens on my machine (Win10) on the latest commit without this PR.

[lucasmerlin]

Thanks!

[lucasmerlin]

I've updated the snapshots. Looks like ci doesn't run all tests if theres a failure, that's annoying.

Unfortunately it looks like this change causes the text edits to shrink a bit, I assume due to the additional spacing introduced due to the extra atom. I don't have a simple idea for this, but I've run into it before. Maybe we can add a flag to atoms whether it should be ignored for spacing?

[RndUsr123]

There's definitely something off, but I'm noticing the opposite: TextEdits added through add_sized are larger than intended though not very consistently so. In my case it's 60 -> 66, 100 -> 108, 140-> 141 and 200 -> 201. This is in screen pixels at 200% scaling (sizes in egui were 30, 50, 70 and 100).

Not sure what may be causing this, but I think there's a good chance there's an underlying problem with how Atom sizes are computed, possibly with Atom::grow() specifically

update: there seems to be an issue how atoms fill the pre-determined TextEdit area in general, not just the extra padding I added. prefix and suffix alone push the TextEdit out of bounds and increase its size from what's supposed to be 60px to more than 100 Look:

update 2: interestingly, hint_text without padding produces the correct final size (with the exception of the 30px one due to minimum size of a single character + suffix and prefix being 43), so there's likely a problem with how the text galley is turned into an atom rather than the general layouting of the TextEdit. Padding is, however, problematic in its own right too because the right one adds an extra 4px (43 -> 47) to the minimum size required.

I'll see if I can find a fix.

[lucasmerlin]

Opened #8026 to address this, it should fix the spacing issue

[RndUsr123]

Yeah, defaulting grow to ignoring spacing is what I was about to suggest as well.

Now there's the second issue, which is the hint taking up the correct amount of space while the text doesn't:

Logically I'd expect the same text to take up the same amount of space, but that doesn't seem to be the case

Edit: while the main text uses clip_text to determine whether its atom is allowed to shrink or not, that's not the case for the hint, which appears to be able to shrink regardless. My hunch is shrink should always be enabled by default for multiline text since even the docs suggest it only works for singleline. Is it a bug it's not triggered in this instance?

[RndUsr123]

This seemingly fixes the issue of the main text not wrapping correctly and apparently doesn't affect clip_text, which still works in single line if no size is manually definied.