dialog.NewProgressInfinite is deprecated, but dialog.NewCustom isn't equivalent

[e1fueg0]

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

dialog.NewProgressInfinite() uses a trick to get rid of dismiss button, but dialog.NewCustom() doens't give such possibility.

Is it possible to construct a solution with the existing API?

Still use dialog.NewProgressInfinite().

Describe the solution you'd like to see:

The simplest way is to not create dismiss button if dismiss string parameter of dialog.NewCustom() is empty.
Or maybe version like dialog.NewCustomWithButtons() or event expose setButtons() method.

[andydotxyz]

Thanks for this. I agree with the general point, though not sure about setButtons() as that isn't a great API even for internal usage.
Perhaps dialog.NewCustomWithoutButtons(), or as you say dialog.NewCustomWithButtons(nil)...

[andydotxyz]

Marking this as blocker so that it is in place for at least one release before deprecations may be removed.

[e1fueg0]

By the way, @andydotxyz , why not leave dialog.NewProgressInfinite(), but refactor it using the new API you were talking about?
Progress dialog creation using a single call is very convenient to use.

[Jacalz]

We deprecated dialog.NewProgressInfinite() because we decided (or perhaps "came to the conclusion" would be a better choice of words) that it is a poor design choice to pop up a progress bar in a dialog, and thus making it impossible to use the rest of the user interface at the same time. It is not something I think we should promote that developers use in their applications. If there is a good use-case to have a dialog without buttons, then I'm entirely in favour of that solution instead.

[e1fueg0]

Hm. There are a lot of tasks which take several seconds to be finished, but it's too complex or too long to stop them, or authors see no need to stop them.

because we decided that it is a poor design choice

In fact, you know, some developers may not agree with this and they will still create infinite progress dialogs, so may be you can provide them with a standard implementation, specially when you already have the API.

[Jacalz]

First of all, I do want this to turn into a long argument back and forth. Let me just clarify my last comment based on your answers. My last comment should have provided some more clarification to begin with.

Hm. There are a lot of tasks which take several seconds to be finished, but it's too complex or too long to stop them, or authors see no need to stop them.

It's not about long tasks that can't be stopped, or such. If someone has a dialog that pops up with a progress dialog, there is often a better way to handle the problem. Go has excellent support for threading and doing things concurrently. If a developer decides that they really need to do this, they can simply make a custom dialog with the same functionality (or so we though).

because we decided that it is a poor design choice

In fact, you know, some developers may not agree with this and they will still create infinite progress dialogs, so may be you can provide them with a standard implementation, specially when you already have the API.

That's not really how you create a good API. We need to provide an API with sensible defaults, by iterating and improving as we go. If that means removing something that we think no longer fits in, we need to do so. There will always be people that use APIs in a way that wasn't anticipated or intended, but that doesn't mean that we should make that easier.

I hope that this clarifies why we decided to deprecate it. Is there any other use-case for dialogs without buttons, except for progress dialogs?

[e1fueg0]

Ok, ok, it's your framework, it's your decisions, no problem =)

[andydotxyz]

Ok, ok, it's your framework, it's your decisions, no problem =)

Apologies @e1fueg0 I think this may have been responded to a bit abruptly. Your comment is a good one and we need to think about it.

@Jacalz The comment on the deprecation notice states that instead of infinite progress the custom dialog should be used, but as noted above it's not the same, as the buttons cannot be removed.
I agree with the intent to remove this discouraged API - however we imply a direct replacement that does not seem to be the case. Perhaps our documentation is misleading...

[Jacalz]

Yes. We (or perhaps mostly I) were certainly wrong in that assumption. It's absolutely something we should fix.

Sorry if that didn't come across in my earlier messages. I just tried to explain why we came to the decision that we did, and I might have worded those answers in a poor way.

[e1fueg0]

No problems at all, guys, you're doing a really great job.

[andydotxyz]

Thanks @e1fueg0.
The question then for @Jacalz or the team is should the documentation to be fixed or should we continue to support some sort of way to have a "no button dialog" that simply does not have a default form such as has been deprecated so we continue to discourage it's usage?

[Jacalz]

If there are more use cases for the "no button dialog", then I think it could be a viable solution. If not, I'm not quite sure if it is worth adding just for creating progress dialogs though. Then I'd say we update the documentation.

[andydotxyz]

I can see that it is easier to imagine to think it will be useful than to say it is always a bad thing ;)

[andydotxyz]

This is frustrating but we decided not a blocker.
We will add some sort of no button custom dialog in a future release, but first we want to get the delayed 2.2.0 done.

[Jacalz]

Indeed. This is technically not a blocker until it is being removed. We’ll get this sorted way before then.

[Jacalz]

We discussed improving custom dialogs on our call this Friday and it seems like we have a path forward. I will try to get that sorted, and thus also solve this, when I have some time over.

[yms2772]

Any update about this discussion?
Custom dialog without buttons are definitely useful, so the fyne framework should give us options to handle dialog freely.
As an example, *os.File or *http.Response is giving the user the freedom to Close() even if the memory leaks are expected.

I think it would be useful in a goroutine like the code below.

go func() {
    noBtn := dialogs.NewCustomWithoutButton(SOME CONTENTS)
    defer noBtn.Close() // or defer noBtn.Hide()

    // any progress
}

[Jacalz]

The update is my comment above. Have not had any time to start working on this yet...

[yms2772]

I implemented a dialog without buttons by making some modifications to the base.go file.
I'll use this until it's officially released.
master...yms2772:fyne:master

[Jacalz]

I have opened #3703. Feel free to test and see if it suits your use cases.

[Jacalz]

I will close this as completed now that the PR has been merged into the develop branch.