Close editor WindowDialogs only when [X]/Close/Save are clicked

[HubKing]

Describe the project you are working on: Hello World.

Describe the problem or limitation you are having in your project: Not about the project, but about the editor UI.

Describe the feature / enhancement and how it helps to overcome the problem or limitation: This is my first time trying the UI, and I have to say, I vastly prefer the accessibility of the editor than that of Unreal (ugly, blurry text) or Unity (cannot change the background colour unless you pay $40 a month). However, when I tried to set a custom theme, the behaviour was frustrating. The "Editor Settings" suddenly disappeared, and I thought it was force-closed by a bug. I then found out that it is closed when I accidentally click outside of the window. On mobile maybe, but that is not how applications work on Windows.

Also, on the colour picker dialogue that pops up when I try to edit the "Base Color", there does not seem to change all three (R,G,B) at once (i.e., adjusting the grey level), so I was trying to type R,G,B values manually. But suddenly the dialogue closes itself whilst I am trying to type a second or third value. It is reproducible every time. See the attached recording below.

Overall, the dialogue close behaviour is frustrating because it does not work as that of other applications.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams: Close the dialogue window only when [X]/Close/Save are clicked as other applications do.

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

Is there a reason why this should be core and not an add-on in the asset library?: Can an add-on change the editor GUI behaviour?

[Calinou]

This behavior is controversial, but many people actually like being able to click out of a dialog to exit it. Maybe we could keep this behavior, but only when double-clicking outside of a dialog. This way, accidentally closing a dialog would become much more difficult, but you'd still be able to exit a dialog without having to aim at a button or press Escape.

Note that in 4.0, modal windows are opened in separate OS windows, which means they're seen as separate windows by the window manager. They will still close if you click the main window again, though.

Also, on the colour picker dialogue that pops up when I try to edit the "Base Color", there does not seem to change all three (R,G,B) at once (i.e., adjusting the grey level), so I was trying to type R,G,B values manually.

Now that I think about it, we should probably allow holding Shift or Ctrl to drag all non-alpha sliders at once (except in HSL mode).

[jonbonazza]

@Calinou in 4.0 when we move to separate windows for dialogue boxes, I am very against closing the windows when you click in the mai. Window.

A) that's not how any other application on any mainstream os works. Users will not expect this and will be confusing. B) this entirely defeats the purpose of having seoarate windows in the first place. If the dialogue is modal then you shouldnt even be able to click any other window--that's what it means to be modal. If it's non-modal, then the whole benefit is to be able to have multiple windows open at once and use them simultaneously.

[Calinou]

@jonbonazza I'd be in favor of keeping them open as well, but reduz implemented it that way when he refactored the windowing system to use DisplayServer. There might be a reason behind this.

[KoBeWi]

Now that I think about it, we should probably allow holding Shift or Ctrl to drag all non-alpha sliders at once (except in HSL mode).

But that's what V in HSV is for. Mostly.

[KoBeWi]

This is resolved in 4.0 by https://github.com/godotengine/godot/pull/39993 The change could be backported to 3.2.x probably.

Also the color picker behavior is a bug (not fixed by above, because it's not a dialog), see https://github.com/godotengine/godot/issues/23626