TextGrid - Random Errors when running the application

[halsten-dev]

Checklist

• I have searched the issue tracker for open issues that relate to the same problem, before opening a new one.
• This issue only relates to a single bug. I will open new issues for any other problems.

Describe the bug

I'm trying to work with TextGrid to craft an editor. But I sometimes getting this error at the start of the app. I just need to restart the app for it to disappear. It seems to only appear if I close the app abruptly with the stop button from Goland.

Any idea what's going on ? I'm running Linux.

How to reproduce

1. Having a widget using a TextGrid.
2. Close the app abruptly (Ctrl+C in term or Stop in Goland)
3. Rerun the app
4. It'll happens sometimes

Screenshots

No response

Example code

type Editor struct {
	widget.BaseWidget

	Grid *widget.TextGrid

	CurrentRow int
	CurrentCol int
}

func NewEditor() *Editor {
	editor := &Editor{}

	editor.Grid = widget.NewTextGrid()

	editor.CurrentRow = 0
	editor.CurrentCol = lineStartCol

	editor.Grid.ShowLineNumbers = false
	editor.Grid.ShowWhitespace = false

	editor.ExtendBaseWidget(editor)

	return editor
}

func (e *Editor) CreateRenderer() fyne.WidgetRenderer {
	return widget.NewSimpleRenderer(e.Grid)
}

Fyne version

2.5.3

Go compiler version

1.23.1

Operating system and version

Linux 6.11.11-1-MANJARO (Wayland)

Additional Information

More docs around TextGrid would be greatly appreciated ;)

[Jacalz]

Can you please provide a fully runnable code example and also specify what error you are getting? That makes it a lot easier for us to test.

[halsten-dev]

Hi,

Of course, here it is with another kind of possible random error. Hope it helps.

error2.txt
demoeditor.zip

I just want to say that's it's a lot of effort to use those TextGrid. I looked in detail of what you guys did for the Fyne terminal, which is amazing by the way.

Maybe at looking at this little piece of code, you could give me some advice and even giving some insight on the why TextGrid are capable to resize the window size when growing in size ? It's blowing my mind.
Actually, just try to manually resize the window in this simple demo. It's slow as hell. I don't understand why I must say.

Thanks for you precious help.

[andydotxyz]

For an editor I would recommend using the Entry widget (probably with monospaced style set).

Any widget will cause the window to expand if their min size is larger than the window allows.

[halsten-dev]

That’s very interesting. How would I manage syntax highlighting ? Line numbers ? Any exemple ? Thanks a lot in advance.

[andydotxyz]

I guess those are not in yet. colouring will be in 2.6 but the line numbers might need to be added in your own code.

It's a tradeoff really - the TextGrid is low level for display so you need to add the editor, the Entry is higher level entry but currently plain text only.

[halsten-dev]

Ok ok thanks for your answer. TextGrid are of course low level but the Fyne's implementation does not really help. I really want to make it work. It could be amazing.

Actually, I was in need in a Table to avoid my cell value to overflow onto the next columns. So I start asking myself how to manage the scroll. I realized by looking at the entry widget that all the scroll concept is fully internal to Fyne. The same applies to the TextGrid. Of course the fact that the TextGrid simply expend the window is a big problem. But, it's not possible, in my understanding, to create a scroll container or something like that outside of Fyne.

In fact, I'm facing the same issue with the simple need of making a progress bar red and another one blue to represent health and mana points. I really love Fyne and I use it a lot. But, once that the needs are a bit specific and outside of the scope, I feel like too much is private and forces to modify Fyne itself. I personally like the approach that I'm doing my own Fyne extension library and add on top of it and still be able to update Fyne as necessary without loosing my additions. And it's seems to me that's the philosophy behind Fyne's API. Like it's described in the docs. If you need something specific, simply extend on your side. Maybe I'm wrong and misunderstanding everything.

But again, Fyne is amazing in a lot of ways.

[andydotxyz]

I realized by looking at the entry widget that all the scroll concept is fully internal to Fyne.

Nope, you can do container.NewScroll and wrap any content.

In fact, I'm facing the same issue with the simple need of making a progress bar red and another one blue to represent health and mana points

The progress bar uses primary colour. You can have different progress bars by wrapping them in container.NewThemeOverride and passing it a theme that changes the primary colour.

If you need something specific, simply extend on your side. Maybe I'm wrong and misunderstanding everything.

Nope you are right about that :)

[halsten-dev]

Oh indeed I completely missed that container ! Guess it's pretty new and did not make it's way to the doc yet.

And I understand now the logic behind the bar coloration ! Once you know it ! 😄

[andydotxyz]

Oh indeed I completely missed that container ! Guess it's pretty new and did not make it's way to the doc yet.

It was added in v1.4, moved from widget to container in v2.0, it's included in the Widget page for historical reasons https://docs.fyne.io/explore/widgets
Probably we just need to organise better to match API refactoring.

[Jacalz]

I personally prefer to use the official pkg.go.dev website for all my API documentation uses. Given that information there is updated automagically when a new package release is pushed, it is always up to date and as it is the official site it moves along feature wise quite a lot. The list at https://pkg.go.dev/fyne.io/fyne/[email protected]/widget has all the widgets, https://pkg.go.dev/fyne.io/fyne/[email protected]/container has all the containers and so on. If you want images and examples then our own docs page is miles ahead though.

[halsten-dev]

Alright, thanks for the very useful advises.

I tried the container.NewScroll in a table. It's not very useable out of the box since when the mouse is on a cell, the scroll event is not sent on the underlying scroll container.

Sorry, I know that's not the subject of this bug report. I should probably open a discussion on the subject.

[andydotxyz]

I would not put a scroll inside a table because nesting scrolls is a bad idea.
However I'm not sure what you're reporting because the scroll events will always be sent to the child-most scrollable widget under the mouse.

As you say though, its a different topic.