Rename the confusingly named WINDOW_MODE_EXCLUSIVE_FULLSCREEN

[KeyboardDanni]

Describe the project you are working on

A game :)

Describe the problem or limitation you are having in your project

The enums WINDOW_MODE_FULLSCREEN and WINDOW_MODE_EXCLUSIVE_FULLSCREEN generate quite a bit of confusion - see here and here.

Godot does not support "exclusive fullscreen", at least in the traditional Windows sense. It only supports borderless fullscreen and uses fullscreen optimizations in Windows (and similar functionality in Linux drivers) to do direct scanout. The difference between WINDOW_MODE_FULLSCREEN and WINDOW_MODE_EXCLUSIVE_FULLSCREEN is that WINDOW_MODE_FULLSCREEN tries to defeat fullscreen optimizations by adding a border around the window to try and force the OS to pipe the window through the compositor (which in some cases might not even work if windowed optimizations are enabled).

Because of the conflicting terminology, and the fact that the more plainly named WINDOW_MODE_FULLSCREEN is not suited for games, this results in a lot of confusion by users.

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

We should rename these enums. Ideally the old names should be totally removed as they're confusing, but that'd need to wait for 5.x. We could also just add new enums and deprecate the old ones, as long as this is visible to the end user in some way.

The new names should clearly indicate what they're intended for. We should not have an enum simply named WINDOW_MODE_FULLSCREEN because users will gravitate toward that as a default when it could be a suboptimal choice for most projects.

Whatever enum replaces WINDOW_MODE_EXCLUSIVE_FULLSCREEN should be higher in the list than WINDOW_MODE_FULLSCREEN, so that users consider it first and only use WINDOW_MODE_FULLSCREEN if there are issues.

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

Some suggested replacement names for WINDOW_MODE_EXCLUSIVE_FULLSCREEN and WINDOW_MODE_FULLSCREEN, respectively:

• WINDOW_MODE_FULLSCREEN_DIRECT and WINDOW_MODE_FULLSCREEN_REDIRECTED - this differentiates the two modes based on whether they try to draw directly to the screen or not, but doesn't explain when you'd typically want to use one over the other. The "redirected" in this case is borrowing terminology from the Linux world, though it might be a bit confusing to some. We could use "indirect" instead.
• WINDOW_MODE_FULLSCREEN_GAME and WINDOW_MODE_FULLSCREEN_APPLICATION - this labels the modes based on what you'd typically use for a game or rich video application versus a non-game application, but slightly obscures what they're doing under the hood.
• WINDOW_MODE_FULLSCREEN_OPTIMIZED and WINDOW_MODE_FULLSCREEN_MULTITASKING - this labels the modes based on whether they're designed to easily allow windows and overlays to appear in front. Although this is somewhat misleading, as newer GPUs and semi-recent versions of Windows support Multi-Plane Overlay which eliminates the need for WINDOW_MODE_FULLSCREEN_MULTITASKING, and depending on your system configuration you can also achieve similar under Linux.

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

Technically?? But that's not the point here.

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

This is a core usability papercut involving engine enums.