fyne.Do confusion

[nagylzs]

While using fyne v2.6.0-rc2, I wrote a widget renderer that has this Refresh method:

func (r RunTreeNodeViewRenderer) Refresh() {
	r.txt.Text = r.nv.txt
	if r.nv.IsSelected() {
		r.rct.FillColor = TreeNodeBgSelected
	} else if r.nv.hover {
		r.rct.FillColor = TreeNodeBgHover
	} else {
		r.rct.FillColor = TreeNodeBg
	}
	n := r.nv.n
	n.RLockTree()
	st, blocked, cl := n.Status, n.Blocked, n.StatusColor(true)
	n.RUnlockTree()
	r.st.Text = rt.StatusEmoji(st, blocked)
	r.st.Color = cl
	fyne.DoAndWait(func() {
		r.rct.Refresh()
		r.st.Refresh()
		r.txt.Refresh()
	})
}

The most important thing is that it calls the Refresh method of other contained widgets. Sometimes I need to call the Refresh() method of this widget. It happens when some attributes are changed. In this particular example, when the node becomes selected or unselected, then it needs to be redrawn with different colors.

All right, if I call the above Refresh() method from the main goroutine then I get this error:

Apr  3 15:54:07.263 INF *** Error in Fyne call thread, fyne.Do[AndWait] called from main goroutine ***

but if I don't use fyne.Do or fyne.DoWait then I get this error instead:

Apr  3 16:00:13.936 INF *** Error in Fyne call thread, this should have been called in fyne.Do[AndWait] ***

You see, the Refresh() method sometimes needs to be called from the main goroutine, but sometimes it needs to be called from another goroutine. So no matter if I use fyne.Do or not, I'll always get an error.

Of course, I can always call go w.Refresh() instead of just calling w.Refresh(), but it has the following disadvantages:

1. spinning up a goroutine just for this seems silly
2. I won't be able to wait for the refresh operation to complete (but sometimes I need to)

The general question is this: how to write a method that calls other fyne methods, and can be called from either the main goroutine and also from other goroutines? What is the preferred way to do this in 2.6 ?

[andydotxyz]

Don't bury fyne.DoAndWait in your widget Refresh, because it should always be called on the correct thread.

What needs to be fixed is when your app calls Refresh() from a background goroutine.

[nagylzs]

Yes, I understand that my renderer's Refresh() method should not be semantically different from any other renderer's Refresh method. But the concept of a "correct thread" was not clear. So you are saying that whenever I call the Refresh method of any widget from anywhere, I must already know if the current call stack is part of the main goroutine or not? Generally speaking, it is not possible to write a function that can be called from both the main goroutine and also from other goroutines. It must either be a "call from main thread" function or a "call from elsewhere function", or introduce an extra parameter. This is very different from the previous fyne version. Some programs (just like mine) will need more refactoring. Migrating to v2.6 cannot be done by simply wrapping specific calls in fyne.Do and fyne.DoWait. Migrating between versions cannot be done formally, it requires semantical analysis, and possibly splitting existing code into different variants.

Thanks for the explanation.

[andydotxyz]

Hmm, thanks for the message, I see that some apps will not know whether or not their code was running in the background. In general the approach would be to assume that fyne.Do is not needed, but to insert it into your code when it does run in a goroutine - i.e. your app is making the assertion.

However all of this is to try to help people migrate safely to the new setup - you can turn off this by marking your app as "migrated" which will remove the safety (and it will be faster). Docs will be published as the release goes live, but you can see this turned on in our example app: https://github.com/fyne-io/fyne/blob/develop/cmd/hello/FyneApp.toml

We are aware that it can be a pain to think about how the code is executing, and I regret that we had to make this change at all - but unfortunately all the work we put into "don't worry about the thread" was slowing things down to the point that it became detrimental. From v2.6.0 onwards apps will be faster AND free of races, but at the cost of thinking about when your code is running in the background.

[andydotxyz]

TL;DR

So you are saying that whenever I call the Refresh method of any widget from anywhere, I must already know if the current call stack is part of the main goroutine or not?

That's not really what I mean. For the most part you should never have to worry in your widget code - only in the code where you run background processing.

[nagylzs]

Yes, for example I have this method that is called whenever the current node changes.

func (nv *RunTreeNodeView) NodeChanged() {
	nv.txt = nv.n.DisplayLabel()
	nv.Refresh()
}

This method also needs to be called from the main thread, because it calls Refresh. Any function that calls NodeChanged() directly must also be called from from the main thread etc. In reality, the current node can be changed from many places, including widget code that is already wrapped in fyne.Do, and other goroutines. I have to keep in mind (and possibly document?) which functions should be called from the main thread and which are not. In a bigger program, when there are a lot of (old) functions calling each other, this can really be a pain. But I also understand that this is the only way to make it efficient.

The general solution for fyne.Do would be:

go func() {
   fyne.Do(func() }
     nv.Refresh()
   })
}

but that's a burden. And I think there is no general solution for fyne.DoWait.

Thank you again

[dweymouth]

I think what may not have been communicated properly is that Fyne now guarantees callbacks to your own code will arrive on main. So whenever you're in something like an OnTapped for button, or event receiver like TappedSecondary, etc, you won't need to use fyne.Do. Indeed you only need to use it if your app code creates a goroutine. Best practice is to make all your custom widgets/UI components use the same model as Fyne itself (e.g. your custom widget can assume all its calls come from main), and then you only have to use fyne.Do where some background task that you spun up has completed and you now want to update the UI.

[nagylzs]

This is very good advice. :-)