This adds the GLFW_SCALE_FRAMEBUFFER window hint, enabling control of
framebuffer scaling across Wayland and macOS. On macOS, this window
hint is a new name for GLFW_COCOA_RETINA_FRAMEBUFFER, and both hint
names will modify the same hint.
This is now a more symmetric counterpart to GLFW_SCALE_TO_MONITOR and,
weirdly, they each apply neatly to half of the supported platforms.
This commit is mostly documentation updates to better integrate and
contrast these two scaling mechanisms.
The calculation of framebuffer size is about to get more complicated
with the introduction of fractional-scale-v1, so only do it in one
place.
This is also a tiny preparation for eventually behaving better towards
wl_egl_window_resize.
We are about to introduce another scaling method (fractional-scale-v1),
so it will become more important to be specific about what scales are
used where and what their units are.
This removes 'content scale' from window and monitor structs. A monitor
(output) now has just a 'scale', which becomes a 'buffer scale' when
applied to a window. A window now has a list of 'output scales' to
select its buffer scale from. Content scales are calculated from the
respective monitor or window when queried, even if the calculation right
now is to just return the same value as before.
When using the fallback decorations, GLFW_HOVERED was true also when the
cursor was over one of the window decorations.
This also disentangles the GLFW_HOVERED state from the fallback
decorations. Because GLFW_HOVERED should have had the same behavior as
GLFW_MAIN_WINDOW, the latter has been removed.
We now have three window decoration paths in the Wayland backend:
libdecor decorations, XDG decorations and fallback decorations.
This makes it clearer when code relates to the fallback decoration path,
which should increasingly (hopefully) not get used.
This implements window focus requests via the xdg-activation-v1
protocol. These requests will likely only work when another window of
the same application already has input focus, but that isn't unlike the
behavior of other platforms.
The GLFW_FEATURE_UNAVAILABLE error has been removed from this function
for now.
Related to #2284
Related to #2306
Related to #2439
- Button label reflects window mode
- Window attention request button
- Slightly less bad button layout possibly
- Applicable button labels list expected delay
- Less telegraphic message for positions being unsupported
- Window size more likely to fit contents
In a Parallels VM wglGetPixelFormatAttribivARB returns fewer pixel
formats than DescribePixelFormat. This broke context creation on
Windows in Parallels since the changes in
2c0f34b60f. The previous version of the
code worked accidentally.
This adds a workaround by iterating through the minimum of both counts.
It should have no effect when running on conforming implementations.
Tested on Parallels by @ dougbinks.
Closes#2191Fixes#2406Fixes#2467
The native access functions for monitor objects did not check whether
the correct platform was initialized and would return invalid handles if
it was not.
This implements window attention requests via the xdg-activation-v1
protocol.
This was updated by @ elmindreda to work with recent Wayland related
changes to the main branch:
- Switched to current way of handling Wayland protocol files
- Added the xdg-activation-v1.xml protocol file to deps/wayland
- Added missing macros to rename protocol interface globals
The protocol file was copied from wayland-protocols 1.33.
Closes#2287
This changes the default platform for Unix-like systems (other than
macOS) from only X11 to Wayland and X11. It also removes the backward
compatibility with the older GLFW_USE_WAYLAND CMake option.
If a bisect took you here because your build broke, hello, sorry, set
the GLFW_BUILD_WAYLAND or GLFW_BUILD_X11 CMake option to disable the
associated platform.
This can be done when configuring GLFW with CMake, from a higher-level
CMakeLists.txt if GLFW is part of your project, or at any point after
configuration by updating the CMake cache with the command-line tool or
the GUI.
The next step is to make Wayland the run-time default when enabled, but
that will hopefully not break any builds.
Related to #2439
