Open dialog from goroutine

[valpo]

I am writing a fyne-app which does some work in the background using goroutines. Now I've tried to report errors within the background tasks to the user using dialog.ShowError. At a first view it seems to work, but it caused some strange behavior. Later I've found out that dialogShowError does not block if called from within a goroutine.
Let's look a some samples:

func main() {
	myApp := app.New()
	w := myApp.NewWindow("Test")
	w.SetContent(widget.NewButton("Click", func() {
		dialog.ShowError(errors.New("Test Error."), w)
		log.Print("After ShowError")
	}))
	log.Print("App starts")
	w.ShowAndRun()
}

The "Test Error" message appears and after clicking on the OK-button the log message "After ShowError" is printed.
Now the goroutine case:

func main() {
	myApp := app.New()
	w := myApp.NewWindow("Test")
	w.SetContent(widget.NewLabel("Wait..."))
	go func() {
		time.Sleep(2*time.Second)
		dialog.ShowError(errors.New("Test Error."), w)
		log.Print("After ShowError") 
	}()
	log.Print("App starts")
	w.ShowAndRun()
}

In this case it logs the "After ShowError" message after 2 secs without waiting to the click on the OK-button.
So it looks like dialogs are only usable from within the main thread.
I am familiar with Qt where I would use Timer-Events for such cases. I haven't found something similar in fyne. How do I start actions in the main thread after the mainloop is running? What patterns do you usually use to handle the above case (reporting results from background tasks to the ui)?

Mathias

[andydotxyz]

Opening a dialog never blocks. Just like showing a window won't.
In Fyne (as many other GUI toolkits) user events occur as callbacks or future method calls not a blocking call when asking to show.

This is not related to goroutines, the behaviour is the same from any code execution.

[Jacalz]

To add to the response from @andydotxyz, you can make a dialog block (sometimes useful in goroutines) by using either a channel or a sync.WaitGroup to block the goroutine after creating the dialog. The dialog callback can then send on the channel or signal done for the wait group to unblock. I've used this in multiple places inside my own projects.

[BillBuilt]

Is there some example code for this? I am running into the same problem. I want an error dialog to block until the button is clicked. The best I've been able to achieve using the above example is that the dialog gets displayed, but then the blocking channel prevents the dismiss button from being clicked. Using sync.WaitGroup exhibits the same behavior.

func main() {
	myApp := app.New()
	w := myApp.NewWindow("Test")
	w.Resize(fyne.Size{
		Width:  320,
		Height: 240,
	})
	bc := make(chan struct{})
	w.SetContent(
		widget.NewButton("Click", func() {
			go func() {
				ed := dialog.NewError(errors.New("Test Error."), w)
				ed.SetOnClosed(func() {
					log.Print("After ShowError")
					close(bc)
				})
				ed.Show()
			}()
			<-bc

			log.Print("After block")
		}),
	)
	log.Print("App starts")
	w.ShowAndRun()
}

[andydotxyz]

By blocking inside GUI code you run the risk of the GUI becoming unresponsive. Which sounds like what is happening.

[Jacalz]

Yup. Blocking inside the goroutine is a lot better

[BillBuilt]

I probably am missing something simple here, but the problem is that the error dialog needs to block any code execution that would come after it is presented. For me, I am checking for problems (db is missing, a dir cannot be found, etc) and if any are found, it should prompt the user with an error dialog that blocks any remaining code from executing and then when the user clicks OK, I want the app to exit. Without it blocking, the app may try to open a DB that doesn't yet exist or cannot be found , thus causing a panic or other fatal error and the dialog would never get presented.

[Jacalz]

Just do what I proposed above about blocking (reading from the channel) inside the goroutine instead and do any DB operations after that. It might make sense to make the channel send an error value and then send the error through it. Where you are reading from it, you can just check if it is nil or not.

[andydotxyz]

Simply blocking is a very bad idea for a GUI app, as you want the interface to remain responsive. Realistically you should put some control flow into your logic so that if there is an error it exits what it was trying to do.