Fluid 0.7.0 has been released! (page 3)

On Thursday, 3 October 2024 at 11:15:16 UTC, cookiewitch wrote:

After 9 months of development and 252 commits later, finally 0.7.0 gets to see the sunlight! This is the biggest update to Fluid yet, almost twice as big as 0.6.0, and also almost half the size of Fluid itself. In fact, so big, that I decided to delay some of the changes to a separate future update; too big.

Fluid is a general-purpose user interface library. It is D first, and comes with Raylib support. While largely a work in progress, and of pre-release quality, it's already mostly stable and ready for use.

0.7.1 is now out and available on DUB. It adds support for Raylib 5.5 and some other, small, miscellaneous changes.

Next updates in the 0.7.x series will still include improved documentation and new nodes, but Fluid is now moving focus to the next 0.8.0 release. To speed up the development process I published a simple guideline for breaking changes. The process is now also becoming more formal, as I am standardizing and writing down practices I've established during development.

November 23

Re: Fluid 0.7.0 has been released!

Posted by IchorDev
in reply to cookiewitch

Permalink

IchorDev

Posted in reply to cookiewitch

Permalink

On Monday, 18 November 2024 at 14:27:41 UTC, cookiewitch wrote:

Measurement and rendering uses the TextRuler struct (frankly more important than the Fluid-centric StyledText one we keep discussing), which I hope to keep super simple so it can be easily manipulated by the user.

Good luck keeping it simple!

It keeps track of the pen position and text size.

This sounds like it would break when RTL text needs to be embedded into LTR text. (because RTL text needs to be right-aligned within the LTR block)

The idea is TextRuler is fed pieces of unbreakable content ("words") which may be text, but it can be anything of known width. A textual word would be first measured and then placed in the ruler to place it in the correct spot in the text.

Whatever manipulates the ruler, like the Text struct, could handle other pieces through a hook that would run between words. I imagine it would have a signature like void delegate(ref TextRuler, WordSize). inline-block-like content (images, buttons, etc.) would increase line height and add a single "word" both matching the image's size. inline elements could add multiple words. float content could be simulated by inserting a word on every line at its supposed location, and thus would even support non-rectangular elements anywhere within the line.

What about the majority of languages which do not use spaces? Do they submit all of their text in one huge block? And surely basing your rendering idioms around the English concept of a word is surely a bit exclusionary, no?

As for TextRulerCache I mentioned earlier, I'm almost sure I've ironed out all the quirks and bugs. I think it's OK now, but certainly coding a pretty weird and complex data structure while having a fever wasn't my brightest idea.

Well done! When it becomes its own package I'll have to have a look at how it's going. :) I might end up doing my own thing if time allows.

On 24/11/2024 9:53 AM, cookiewitch wrote: > What about the majority of languages which do not use spaces? Do > they submit all of their text in one huge block? And surely basing > your rendering idioms around the English concept of a word is surely > a bit exclusionary, no? > > I… don't know? My idea of a "word" here is any unbreakable unit. I guess I have another round of looking up Unicode algorithms ahead of me. Unfortunately word breaking isn't a simple algorithm to implement. https://www.unicode.org/reports/tr29/#Word_Boundaries White space and punctuation alone cannot differentiate words. Nor can it be used to fake identifiers in a programming language.

On Monday, 20 January 2025 at 00:19:44 UTC, Richard (Rikki) Andrew Cattermole wrote: > On 24/11/2024 9:53 AM, cookiewitch wrote: >> I… don't know? My idea of a "word" here is any unbreakable unit. I guess I have another round of looking up Unicode algorithms ahead of me. > > Unfortunately word breaking isn't a simple algorithm to implement. > > https://www.unicode.org/reports/tr29/#Word_Boundaries > > White space and punctuation alone cannot differentiate words. > > Nor can it be used to fake identifiers in a programming language. Additionally many words are actually break- -able because you can hyphenate them to wrap over multiple lines neatly. Books and news- -papers employ this technique more frequently than most other mediums due to limited page space and printing costs. However, when space isn’t physically limited (and a book or newspaper are not being emulated), breaking up words is unfavourable because it compromises readability. So it’s nice to have a word breaking option (for when emulating printed media is desirable, like rendering a newspaper texture that has randomly generated text), but it should by no means be the default. And it’s a lot of work for such a subtle and language-specific feature.

Forums