Synchronous Method for Showing `MessageDialog`

[ndianabasi]

Is your feature request related to a problem? Please describe.

Currently, a message dialog usage looks like the code below where the callback per button are asynchronous.

        app.Dialog.Question().
            SetTitle("Migration Warning").
            SetMessage(fmt.Sprintf("%d migrations are available. Do you want to run them now?", len(pending))).
            SetDefaultButton(&application.Button{
                Label: "Run",
                IsCancel: false,
                IsDefault: true,
                Callback: func() {
                    doMigrations()
                },
            }).
            SetCancelButton(&application.Button{
                Label: "Cancel",
                IsCancel: true,
                IsDefault: false,
                Callback: func() {
                    log.Println("Migration cancelled by user.")
                },
            }).
            Show()    

The challenge with this pattern is that, there is no way of returning error or result from each callback function synchronously so that the application can take critical decisions such as exiting the application if a critical request was rejected by the user.

Describe the solution you'd like

I am suggesting a new synchronous method like ShowSync which returns the error and result from either callback function assigned to the buttons.

If feasible, we could also introduce generics so that the result returned from the cancel or default buttons are type safe.

Describe alternatives you've considered

The current implementation in v3 is asynchronous. The v2 implementation was synchronous and similar to the above request. However, the callbacks will be called to return result or error instead simply returning the button labels as the result.

Additional context

No response

[leaanthony]

Do you think returning a result and error might be too far for the callback? The idea is just a shortcut for when the button is clicked. If we add error and results then it gets a bit nested. Would returning the label be sufficient and you don't bother using the Callback, just switch on the value?

[ndianabasi]

If we add error and results then it gets a bit nested. Would returning the label be sufficient and you don't bother using the Callback, just switch on the value?

Simply returning the label is totally sufficient. That's basically how it worked in v2. Thank you.

[leaanthony]

@ndianabasi - Please try the linked PR 👍

[ndianabasi]

@ndianabasi - Please try the linked PR 👍

I've submitted some comments on the PR @leaanthony. Thank you for your efforts.