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.
