Add bold and underline functionality

[mgazza]

Punt/ Preview PR
Change the font to one that has a bold derivative - (I probably should use fyne bundle instead of go embed).
Add the handling code for supporting underlining and bold.
Make that info available for downstream consumption for fyne.

depends on :
#45
fyne-io/fyne#4244

[andydotxyz]

(converted to draft on GitHub rather than in the text)

[andydotxyz]

Trying to come back to a backlog of PRs and I see this one - it seems to have blinking work in it as well, maybe the wrong base branch?
Also as there is discussion about underline and strikethrough in TextStyle I wonder if that changes the API design here?

[mgazza]

Hey, sorry I've been really busy with other things recently. Certainly there's mention of blinking in this PR. That is because it depends on #45

[mgazza]

depends on
fyne-io/fyne#4244
#85 ( cherry-picked into this )

[andydotxyz]

I had a glance through this, I'm not sure about the weight of the renderer on this - it seems like a lot of TextGrid is copied in, but I'm not sure why.

[mgazza]

I can't encapsulate it because the renderer isn't exported. This a huge issue IMO. I don't know the best way to resolve it.

[mgazza]

We could move the blinking down to the text grid render but I'm not sure what value that would give

[andydotxyz]

I can't encapsulate it because the renderer isn't exported. This a huge issue IMO. I don't know the best way to resolve it.

But why do you need to tweak the renderer implementation? Can't it be delegated to?

[mgazza]

For blink I need to swap the fg and bg colours and I can either do that in the renderer or via the style. Previously I did this via the style and created an interupt which did the blink. ( in the history of the pr ). This was the second approach which you suggested would be better. In terms of delegate, what are you suggesting?

…

On Mon, 17 Jun 2024, 19:43 Andy Williams, ***@***.***> wrote: I can't encapsulate it because the renderer isn't exported. This a huge issue IMO. I don't know the best way to resolve it. But why do you need to tweak the renderer implementation? Can't it be delegated to? — Reply to this email directly, view it on GitHub <#46 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD3ZWQ5KTCCHTMDPNDNJQSTZH4U6TAVCNFSM6AAAAAA6FC422OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZUGE4DMNZUGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[andydotxyz]

For blink I need to swap the fg and bg colours and I can either do that in the renderer or via the style.

Oh I see, this pattern was adopted earlier - I kinda missed how much was duplicated sorry.
Something between the two was in my head. The first was new public APIs which were not needed, and putting it all in the renderer is fine but we've got much more code to manage now.

What I had thought was happening before was that the style information was being used as the source, internally it was toggling when blinking and so the renderer had the updated model to get the visuals right. The TextGridStyle is an interface after all so it can return different colour values as it blinks. By delegating I meant that we encapsulate a TextGrid (along with its renderer) and provide a layer on top that manages complex things like toggling blink or handling hyperlink taps etc... the core rendering is still in the UI library...

But that leaves us with this PR. Is it right to pull in all the new code from Fyne TextGrid here to get the copy of the code working as it is upstream? I guess we kindof have to with what is in place now? Unless a simplification refactor could be done first?

[mgazza]

Can we make the renderer public is the question? That or provide something that we can hook into to say which color we should use. However adding such methods kind of break the open close principle

…

On Wed, 19 Jun 2024, 14:18 Andy Williams, ***@***.***> wrote: For blink I need to swap the fg and bg colours and I can either do that in the renderer or via the style. Oh I see, this pattern was adopted earlier - I kinda missed how much was duplicated sorry. Something between the two was in my head. The first was new public APIs which were not needed, and putting it all in the renderer is fine but we've got much more code to manage now. What I had thought was happening before was that the style information was being used as the source, internally it was toggling when blinking and so the renderer had the updated model to get the visuals right. The TextGridStyle is an interface after all so it can return different colour values as it blinks. By delegating I meant that we encapsulate a TextGrid (along with its renderer) and provide a layer on top that manages complex things like toggling blink or handling hyperlink taps etc... the core rendering is still in the UI library... But that leaves us with this PR. Is it right to pull in all the new code from Fyne TextGrid here to get the copy of the code working as it is upstream? I guess we kindof have to with what is in place now? Unless a simplification refactor could be done first? — Reply to this email directly, view it on GitHub <#46 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD3ZWQZDQYCYUGUB4SDHNTDZIGAKHAVCNFSM6AAAAAA6FC422OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZYG4YDCOJYGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[andydotxyz]

No, renderers cannot be made public. However is the BgColor and FgColor being methods not exactly the thing you need to be able to influence the colours on any particular render pass?

[mgazza]

Right but the blinking state would need to be accessible for us to return the correct color.

…

On Wed, 19 Jun 2024, 15:08 Andy Williams, ***@***.***> wrote: No, renderers cannot be made public. However is the BgColor and FgColor being methods not exactly the thing you need to be able to influence the colours on any particular render pass? — Reply to this email directly, view it on GitHub <#46 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD3ZWQ77NWDRWMTTPOGSX6TZIGGFNAVCNFSM6AAAAAA6FC422OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZYHAYTIMRRG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[andydotxyz]

In my mind that is where our "wrapping" widget comes in - we know the original state and we track a blink flag, toggling the state that is passed into the embedded TextGrid

[andydotxyz]

Anything more I can do to help with the tidy-up here?

[mgazza]

If it's not public, we can't employ consumption over inheritance. Could you maybe take a stab at what your thinking here?

[andydotxyz]

If it's not public, we can't employ consumption over inheritance. Could you maybe take a stab at what your thinking here?

I don't understand this question sorry. My point about blinking was that the colours are being asked for from an interface - and we can return different colours for the fg/bg as the blink occurs. Internally we manage blink state but the renderer would remain entirely the standard textgrid as we are just manipulating the widget state - no need to hook into a renderer.

[mgazza]

Blinking is already in the main branch. This PR is about bold and underlining. I think I'm confused as these couple of features have been left for awhile.

[andydotxyz]

The discussion, as far as I'm aware, is what was done with blinking is now resulting in constantly pulling renderer from upstream Fyne into this project to maintain a tweak for blinking.

I don't know if it was missed at the time but this is really undesirable, causes a maintenance overhead and goes against the design of widget and renderer separation.

This PR should be trivial but because of earlier decisions it is not - this is what I was hoping we could resolve.

If you are keen to land this feature we could back out the blinking, add this in easily, and then review the renderer situation with fresh eyes to get blinking back?
I think it's not until this PR demonstrated the tight coupling that had been introduced that I realised how much of an issue it was.

[mgazza]

it was discussed here.
the previous commits were a lot less invasive.
I wonder if the way forward is to push this widget down into fyne?

[andydotxyz]

I wonder if the way forward is to push this widget down into fyne?

I don't understand this - the widget is already in Fyne. What exists here seems to be a copy/paste of the renderer which you're now working to keep in sync as the upstream widget changes.

[mgazza]

The widget for a text grid exists in fyne, but it doesn't respect The Open-closed principal, the term grid was added in #45. This PR add's bold and underline to the termgrid. The confusion may come from the diff as the termgrid renderer was moved to its own file in this commit

[andydotxyz]

I'm not confused and have tried to outline before that I am aware this is not new code but has come to light it's tight connection to an existing widget.

Without getting into the semantics of it all widgets are open to extension so I don't think it's correct to say that it's not open-closed. I have illustrated above ways that I think it is in fact possible to do what was achieved through copy and paste last time.

Do you think it is untrue to say that without the copying out of the renderer this PR would have been far simpler?

I think the issue is on me for having agreed to cloning the renderer in the first place, I did not fully understand how tightly this caused the two to be tied - which is what has become clear in this PR.

I hope this explains at least my previous messages, I don't think that I am confused about the scope of this change. But with the required render changes it looks like this requires more custom rendering which is not the case.