November 22

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

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.

November 23

On Saturday, 23 November 2024 at 11:58:06 UTC, IchorDev wrote:

>

On Monday, 18 November 2024 at 14:27:41 UTC, 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?

Everything is exclusionary. You go to a restaurant it doesn't have menus in every language on earth, just their native language probably.

The question is not "is it exclusionary", the question is "Is it reasonable to expect them take on the extra burden of catering to X,Y and Z".

Do you think it is reasonable to expect him to cater to your needs given that he is a lone developer working on a fairly large project, and he's doing it unpaid and giving it away for free.

Do you think it is reasonable for you to effectively guilt trip him about being exclusionary?

November 23

On Saturday, 23 November 2024 at 11:58:06 UTC, IchorDev wrote:

>

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!

šŸ˜†

>

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.

November 23

On Saturday, 23 November 2024 at 12:53:30 UTC, claptrap wrote:

>

Do you think it is reasonable for you to effectively guilt trip him about being exclusionary?

No need to be defensive. Having full Unicode support may be beyond my knowledge and skills, but it is why I am open to feedback. I'm thankful for the advice I have received, even if it might be overwhelming at times.

1 2 3
Next ›   Last »