Add bold and underline functionality #46
Conversation
andydotxyz
changed the title
|
(converted to draft on GitHub rather than in the text) |
mgazza
force-pushed
the
add-bold-underline
branch
2 times, most recently
from
fa0ae3b
to
be74aa6
Compare
|
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? |
|
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
force-pushed
the
add-bold-underline
branch
from
be74aa6
to
43baa67
Compare
depends on |
mgazza
force-pushed
the
add-bold-underline
branch
from
43baa67
to
b4a2dc9
Compare
|
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. |
|
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. |
|
We could move the blinking down to the text grid render but I'm not sure what value that would give |
But why do you need to tweak the renderer implementation? Can't it be delegated to? |
|
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:
***@***.***>
|
Oh I see, this pattern was adopted earlier - I kinda missed how much was duplicated sorry. 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? |
|
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:
***@***.***>
|
|
No, renderers cannot be made public. However is the |
|
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:
***@***.***>
|
|
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 |
|
Anything more I can do to help with the tidy-up here? |
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