Fluid 0.7.0 has been released!

[IchorDev]

On Sunday, 3 November 2024 at 12:13:07 UTC, cookiewitch wrote:
> On Saturday, 2 November 2024 at 17:33:19 UTC, IchorDev wrote:
>> [...]
>> Sure, that sounds like a great idea!
>>
>> Here are my thoughts about what could be changed based on how 
>> `fluid.text` is currently set up:
>> [...]
>> - `TextStyleSlice` uses a palette right now, which is 
>> pointlessly limited to 256 different items. It might be worth 
>> attempting to use a `SumType` containing each individual 
>> styling option, since then the defaults don't have to be 
>> re-specified with 1 exception every time someone uses **bold** 
>> or *italic*. Otherwise, `TextStyleSlice` should probably use a 
>> `size_t` for style indices. Also, things like colour that do 
>> not affect text layout should not be part of the `Style` used 
>> when making layouts in the first place. A user's renderer can 
>> worry about that.
>
> Inline styling of `Text` was just a dirty hack to have syntax 
> highlighting working instead of offering a proper, full 
> solution, so it's far from being the final design. Some of my 
> concerns:
>
> * How would you approach coloring text from the user's 
> perspective?

I think we should give users the tools to do rendering 
themselves, which lets them implement non-layout features like 
colour on top however they please. For instance, when colour is 
updated the layout remains the same, so colour can be denoted by 
a structure on the user’s side that the renderer reads from.

> * What about handling text mixed with other content (like 
> images, icons, UI components), something akin to CSS `display: 
> inline-block`?

That’s a tricky one!
I was thinking that an API to add shapes that the text ‘goes 
around’. The shape type would be a sumtype of different shapes, 
probably stored in an optimisation structure like a tree.
But what if you want an *inline* rectangle that will move 
depending on the text layout? For that case we *could* ask that 
the user just get the position that the text ends, place their 
element manually, and then use a second layout object, with the 
first line set to start after the end of the element. I 
acknowledge that’s a lot of work on the user end, but I’d argue 
that it’s an obscure (and frankly absurd) use-case, and requires 
a lot of implementation-specific decisions that make it 
impossible to account for everyone’s needs with our own 
implementation. Can the rectangle overflow the margins at the end 
of a line, or does it wrap? How is the line with the inline 
rectangle on it vertically aligned? How and when can shapes 
intersect with text if at all?
Placing icons inline could probably work the same way as 
image-based emoji, and we could provide a function to add 
surrogate image glyphs (either to a font or to a layout? Not 
sure) for people who don’t want to make a font just to write 
their custom icons. There’s a whole section of Unicode code 
points set aside for ‘private use’ like this.

> Looks good to me. Having a separate structure for static and 
> dynamic text is reasonable, and as you've seen Fluid currently 
> only distinguishes between this at runtime. I'd opt for a 
> regular struct instead of mixin, though.

The mixin template there is just for shared code and wouldn’t 
have any meaningful functionality on its own. It’s also the kind 
of thing that might be better as a string mixin due to sections 
of 100% duplicated code needing to call non-duplicated functions.

> I've introduced a `TextRulerCache` structure which maps 
> characters (by index) to position in text in a way that also 
> preserves layout data, so a piece of text can be edited without 
> recalculating the layout for the rest of it. I'm not very proud 
> of it, it's apparently very fragile, so I'm curious what is 
> your idea of handling this, too.

I *think* (but I could be wrong) that text can’t transcend 
line-breaks. If I’m right then perhaps text could be segmented at 
line-breaks, and then requesting to lay out and render it could 
be done by requesting an index range. And then the dynamic Text 
type needs an interface to report whether a certain range of 
lines is ‘clean’ (unmodified since last calculation) and an 
interface to mark lines as clean. Note that this **requires** 
special user-side handling for top-to-bottom text, making it more 
of a pain to use.