Fluid 0.7.0 has been released!

[cookiewitch]

On Thursday, 31 October 2024 at 13:08:55 UTC, IchorDev wrote:
> On Friday, 25 October 2024 at 12:49:36 UTC, cookiewitch wrote:
>> [...]
>>
>> I'd really appreciate it if there were some other, more 
>> comprehensive learning resources. Do you know any?
>
> Sorry for my late reply! Anyway, here we go…
>
> [...]
>
> Some consideration should be given to where to start. For 
> instance, one could build up from HarfBuzz. However, HarfBuzz 
> is another GLib-based FSF C library, just like Pango, so 
> perhaps this would just shift the compromises further down the 
> line. Say we want *no* compromises; then we have to do 
> everything 100% in D. Certainly neither of these options are 
> trivial, and it would be a fool's errand to embark upon them 
> alone.

Thank you for dedicating your time to this, and for the very 
elaborate response! Reimplementing PangoLayout does sound like an 
option, but as far as I've seen, Pango operates on strings all 
the way through. I suppose it is possible to assemble parts of 
the rope into a string on the stack, and only operate on a single 
part at once, but I don't think this is going to be very 
bug-proof. Alternatively, Fluid's text engine does distinguish 
between static and dynamic text with an "edit mode" flag, so it 
could be possible to apply Pango on stringified static text, but 
that's never going to be enough.

Oh, and also, since Pango is LGPLv2 licensed, I think a port of 
`PangoLayout` could run into licensing problems the way D 
programs are usually built \[with DUB\].

> Having a full D text layout engine is a pet dream of mine of 
> course, so if you're interested in contributing to a project 
> like that then I might be able to dedicate some of my spare 
> time to it.

I've been thinking about this last week and I'm under the 
impression this is what is going to happen anyway. For what it's 
worth, I'm currently working on another large PR which upscales 
Fluid's text engine, splitting it into a separate `fluid.text` 
package and optimizing it on the way through. It is mostly 
standalone, so if you find it appropriate, I could create a new 
Git & DUB repository for it once I'm done. I would like to have 
your input on it.