godotengine / godot-proposals

Godot Improvement Proposals (GIPs)
MIT License
1.16k stars 97 forks source link

Implement a native yes/no dialog. #10604

Open RadiantUwU opened 2 months ago

RadiantUwU commented 2 months ago

Describe the project you are working on

Godot

Describe the problem or limitation you are having in your project

When godot crashes, even though you can take control of the display server and/or rendering server, you still have no way to ask the user things like a yes/no dialog. The objective here is to be able to ask the user when godot crashes if they want to save their project or not.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

DisplayServer.dialog_confirm(title: String, content: String) -> bool would return the value. Note the omission of Cancel here.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

We can already implement it for macOS by it using dialog_show internally. Then there's Windows, Linux, Android, possibly iOS

If this enhancement will not be used often, can it be worked around with a few lines of script?

No

Is there a reason why this should be core and not an add-on in the asset library?

There is future usage here for the game developers if they want to create a crash handler for their game to allow saving it.

AThousandShips commented 2 months ago

What would be different between this and just using dialog_show with a Yes and a No button? What would this do behind the scenes with that method to achieve the same? Would it decorate it in some special way?

bruvzg commented 2 months ago

We can already implement it for macOS by it using dialog_show internally. Then there's Windows, Linux, Android, possibly iOS

dialog_show is implemented on Windows as well.

When godot crashes, even though you can take control of the display server and/or rendering server, you still have no way to ask the user things like a yes/no dialog.

Not sure if it would be any useful for the case of crash, native dialogs still require message loop to be running to be fully functional.

RadiantUwU commented 2 months ago

dialog_show is implemented on Windows as well.

Didnt know, is it also implemented for most platforms?

Not sure if it would be any useful for the case of crash, native dialogs still require message loop to be running to be fully functional.

We can just force input processing with display server, thats not an issue.

RadiantUwU commented 2 months ago

What would be different between this and just using dialog_show with a Yes and a No button? What would this do behind the scenes with that method to achieve the same? Would it decorate it in some special way?

If dialog_show doesn't use a native way to show a dialog, this would do it.

I think some platforms cannot just do what dialog_show does. So this would be good specifically for yes/no.

AThousandShips commented 2 months ago

What platform would not support native dialogs in general but only confirmation dialogs? But you suggested using dialog_show internally? If there's a native way to specifically show an confirmation dialog that'd be a different question and that'd make more sense to me, as:

Calinou commented 2 months ago

The objective here is to be able to ask the user when godot crashes if they want to save their project or not.

I would probably always save the project in this case, but to a dedicated path (e.g. suffix the file name with _crash_<timestamp>. When reopening the project, check for the existence of _crash_* files and ask the user to recover the crash data (i.e. open the crash file instead of the original file, and make it save over the original file if the user saves the project later on). This is more or less what LibreOffice does to handle crash recovery.

timothyqiu commented 2 months ago

The objective here is to be able to ask the user when godot crashes if they want to save their project or not.

This proposal is not the right solution to your problem, I believe.

You can't reasonably access your edited project when a crash happens in the first place. This is not something a native dialog can solve.