Changed default window style to be single window

[Duroxxigar]

Changes the default setting for the window style to be single window, which is current (pre-4.0) Godot workflow. I imagine it was a setting that just forgot to get changed back to true after work on it was completed.

https://twitter.com/reduzio/status/1235887984060362753

[clayjohn]

When you run the editor in 4.0 are the docks floating by default? For me they aren't so I'm wondering what is going on.

I'm on Windows 10, maybe the behaviour is different between OS'? At any rate, it seems like there is more going on here than is apparent at first.

[Calinou]

Since multiple window support is one of Godot 4's largest features, it'd be a shame to turn it off on platforms where it's supported. Keep in mind it allows other things than floating docks, such as:

• Moving modal windows such as the Project Settings outside the editor window.
• Letting tooltips and PopupMenus display outside the editor window.

[Duroxxigar]

It's not removing the functionality. The functionality is still there, it's just making it not on by default, as it wasn't supposed to be on by default based on what reduz said.

@clayjohn Yes, when I run the editor (w/o this change) - the docks are floating by default. By changing these two lines, it turns it off by default. I'm on Windows 10 as well btw.

EDIT: I was mistaking floating docks and floating windows. Floating windows IS on by default. (Separate windows from Godot that is)

[akien-mga]

https://twitter.com/reduzio/status/1235887984060362753

I don't think that's what @reduz is referring to here. He mentions the floating docks, i.e. the possibility to have the docks in separate windows.

In the current master branch, docks are not in separate windows by default. They can be made floating, but that's not the default, which is what Juan refers to.

What this setting enables is to prevent having anything in external windows, and especially popup dialogs. That's not meant to be the default, popup dialogs are meant to be in external windows, unless you use a tiling VM, which is why this setting was added.

[aaronfranke]

I would very much prefer having all pop-up windows be application provided by default. The separate pop-up windows are very buggy for me and seem far less elegant than the 3.x pop-up windows. I don't know why people prefer using their WM for pop-up windows, but single-window should be the default.

There's also the fact that controlling where windows go isn't possible in Wayland. I read some discussions a few years ago that this was by design and is why the Wine devs will never support Wayland except via XWayland. This may cause problems for Godot, since I noticed that the buttons on the top-left corner open up separate borderless windows right now.

https://bugs.winehq.org/show_bug.cgi?id=42284 One problem is for example that a program can not specify the location of a newly created window. This doesn't sound very problematic at first, until you notice that drop-down / popup menus are also just normal windows on Windows. The solution that Wayland provides for this is not really compatible with the Win32 API. I therefore talked with some Wayland developers and there is no chance of fixing this in the future. It is part of their concept that applications should not have control over the window position and similar settings.

[Duroxxigar]

@Calinou Right - this is the setting that allows you to move the stuff off Godot's application window. Pre-4.0, you can't do that. Changing this setting makes it behave in that exact same manner. I admit - I did slightly misread what reduz was saying with the popups vs docks thing, but this setting affects both of them.

At the end of the day, do w/e ya'll want. This PR is here if you want to accept it or not.

[akien-mga]

The separate pop-up windows are very buggy for me and seem far less elegant than the 3.x pop-up windows. I don't know why people prefer using their WM for pop-up windows, but single-window should be the default.

It's buggy because it's a work in progress, but having the bugs present in the master branch should be an incentive for relevant developers to figure out how to fix the bugs.
Hiding the bugs by reverting to the previous behavior may mean that bugs won't be noticed nor fixed.

Further down in the development we can assess which behavior we want as default, but for now it's good to eat our own dog food.

[aaronfranke]

That makes a lot of sense, now isn't the time for this. I'm going to close this, but I highly encourage @Duroxxigar to rebase and re-open this PR once 4.0 is in an alpha/beta state, since I do still think that this change should be made for 4.0's release.

P.S. We don't really have a label for "we'll get back to this later" but I don't think leaving it open is a good idea, we should try to minimize the amount of open PRs. I guess "salvageable" works.