If Ubuntu is not mistaking me, on Wayland `FLAG_WINDOW_HIHDPI` could just be ignored because the window decorator (or whatever subsystem in charge) already rescale the window and its content according to the display scale.
According to my understanding of current GLFW version, on Wayland, the only way to move the windowed window from one monitor to another is to toggle it to fullscreen twice (since only a fullscreen window can be moved to another monitor by code).
Because Wayland does not let know or set the position of a window, it broke some basic Raylib's features and functions. I tried to find a balance between crossplatform compatibilities, and the Wayland way of doing things. So, on Wayland, `SetWindowMonitor()` won't move a windowed window from a monitor to another, but can be used to select on which monitor the user wants the hardware fullscreen mode.
Using `glfwGetWindowPos()` or `glfwSetWindowPos()` trigger errors that should be cleared with `glGetError(NULL)` to avoid misinterpretation of later use of `glGetError()`
Call `WindowSizeCallback()` manually so we don't have to wait for after the next `EndDrawing()` to have access to up to date `GetScreenWidth()` etc value.
Trying to go straight forward from one fullscreen mode to another make things more complicated to control.
Seems a full loop is required when trying to change fullscreen modes and window size properly for now.
Maybe will restore the ability to jump from one fullscreen mode to another when more cleaning will be done deeper in the rabbit hole.
should fix issue #4149
Linux MATE : tested
Macos : tested
Windows : need confirmation
---
thanks to @SoloByte and to @paulmelis for their help and efforts to solve this issue
If `FLAG_WINDOW_HIGHDPI` is set, `InitPlatform()` will aks GLFW to handle resize window content area based on the monitor content scale using : ` glfwWindowHint(GLFW_SCALE_TO_MONITOR, GLFW_TRUE); `
So `WindowSizeCallback()` does not have to handle it a second time.
This could potentially be a breaking change, for consistency, now every possible desktop backend has the proper name assigned: GLFW, SDL, RGFW
raylib build system has been reviewed to fallback to `PLATFORM_DESKTOP_GLFW` by default when `PLATFORM_DESKTOP` defined
* Fix Makefile issues (RGFW) (linux) (macOS)
* Do not use nanosleep on windows at all (PLATFORM_DESKTOP_RGFW)
* remove #define RGFWDEF and make the #undefs only happen for their OS
* Update RGFW.h
* fix to match the RGFW updates
* remove line that shows the cursor for no reason
* Update RGFW, replace long switch with an array, update rgfw platform for RGFW
* update RGFW (fix reported glitch with drag and drop files) (linux)
* remove u16
* Fix Makefile issues (RGFW) (linux) (macOS)
* Do not use nanosleep on windows at all (PLATFORM_DESKTOP_RGFW)
* remove #define RGFWDEF and make the #undefs only happen for their OS
* Update RGFW.h
* fix to match the RGFW updates
* remove line that shows the cursor for no reason
* Fix Makefile issues (RGFW) (linux) (macOS)
* Do not use nanosleep on windows at all (PLATFORM_DESKTOP_RGFW)
* remove #define RGFWDEF and make the #undefs only happen for their OS
* fix minor bugs and errors (x86) for the RGFW platform, update RGFW platform license, update makefile info for RGFW platform
* revert
* (RGFW) (winapi) fix mouse hide bug when cursor changes
* ensure PLATFORM_SHELL is defined (PLATFORM_RGFW)
---------
Co-authored-by: ColleagueRiley <ColleagueRiley@gmail.com>
* Implementing GetMonitorWidth/Height and GetMonitorPhysicalWidth/Height for drm
Added implementation for DRM for functions :
- GetMonitorWidth()
- GetMonitorHeight()
- GetMonitorPhysicalWidth()
- GetMonitorPhysicalHeight()
- GetMonnitorName()
These functions take an argument but only the value 0 is accepted. This is because the DRM platform implementation manages only one screen for now
* Refactor "GetMonitor" properties for DRM Platform
Refactored GetMonitorHeight, GetMonitorWidth, GetMonitorPhysicalHeight,
GetMonitorPhysicalWidth and GetMonitorName to accept only argument "0"
as more than one screen is not supported in DRM platform.
* Rework window placement and dimensions for multi-monitor setups;
- fullscreen apps use primary monitor, exclusively
- non-fullscreen apps come in two variants:
a) pre-determined window size by user
b) use-active-monitor dimensions by user specifying 0x0
Either way, the window shall be centred at the monitor where it was created
This may have been the original intent, yet the primary monitor was used also for the second case, regardless where the window opened.
* Clean up code, handle error, fix integer-overflow for centering windowed fullscreen
The way the current code worked was by calling `GetCurrentMonitor()`,
which would always return the monitor at position (0,0). This isn't the
primary monitor on all platforms, on Linux in particular it isn't the
case.
This isn't the case on the SDL backend, after calling `InitWindow()` the
window would always show up on the primary monitor. Even on the GLFW
backend, if the full screen flag was set it would attempt to put it on
the primary monitor as it would call `glfwGetPrimaryMonitor()` to do it,
so for consistency's sake we should do it on windowed mode too.
The key handling in PLATFORM_DESKTOP_SDL was faulty in two ways, which
led to GetKeyPressed returning incorrect data.
CORE.Input.Keyboard.keyPressedQueue was updated only on SDL_TEXTINPUT,
meaning only text characters were registered as a pressed key, but not
function keys (eg. tab, backspace...). Also on such event, both
CORE.Input.Keyboard.keyPressedQueue and
CORE.Input.Keyboard.charPressedQueue were assigned the key's
corresponding codepoint, when CORE.Input.Keyboard.keyPressedQueue
should get the raylib keycode instead.
CORE.Input.Keyboard.keyPressedQueue is now updated on SDL_KEYDOWN event
instead.
Co-authored-by: Arthur <hi@thenightwat.ch>
