Fluid 0.7.0 has been released!

cookiewitch artha at samerion.com
Sun Nov 3 12:13:07 UTC 2024


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

> - The `Typeface` interface expects implementations to have way 
> too much state.

`Typeface` is something I'm not very happy about either.

> So all in all, a bit like this example: [...]

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.

I think it's worth noting that I also care about maintaining 
performance for large files (100K–10MB), which is what I'm 
attempting to fix on the 
[text-input-ranges](https://git.samerion.com/Samerion/Fluid/src/branch/text-input-ranges) branch, but I'm still struggling. Fluid will only draw the text that is visible on the screen (which is handled by `CompositeTexture`).

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.


More information about the Digitalmars-d-announce mailing list