SuperUserNameMan

Ok so if I replicated @fishbowlforever issue correctly, and if @fishbowlforever uses the GLFW backend, i think the culprit is here : https://github.com/raysan5/raylib/blob/9764fef26260e6fcf671ddffb230360cc1efa1f8/src/platforms/rcore_desktop_glfw.c#L1670-L1682 I think that it is not required...

@fishbowlforever : Did you use the code example i provided ? If not, could you please share a minimal code example of your own so i can see if there...

~~@SoloByte : It change nothing for Macos. There should be no diff.~~ > @SuperUserNameMan can confirm that disabling resizable flag before entering fullscreen helps & can´t test it on macOS...

> @SuperUserNameMan I have not tested it with the new patch ok then, let's start again from a fresh code base then.

@SoloByte > > > @SuperUserNameMan I have not tested it with the new patch > > > > > > ok then, let's start again from a fresh code base...

@fishbowlforever If you use `FLAG_WINDOW_HIGHDPI` at the same time as `ToggleFullscreen()`, they are currently incompatible. You have to choose one or another ~or replace `ToggleFullscreen()` with `ToggleBorderlessWindowed()`.~ **edit** if you...

Could you please test this PR #4151 ?

Hope you don't mind me interfering, but anything that relies on `glfwGetWindowPos()` would fail on Wayland platform, because it does not allow to know the position of a window.

As reported by @paulmelis here https://github.com/raysan5/raylib/issues/4147#issuecomment-2219636084 The behavior is slightly different depending on where the desktop menu bar is located. My current tests confirm that when the menu bar is...

| Menu bar position | Borderless Window position (1st toggle) | Window restoration (2nd toggle)| comment | |-------------------------|--------------------------------------|----------------------------|-----------------| | bottom | `{ 0 , 0 }` | decoration not restored...