The GLFW_PLATFORM_UNAVAILABLE error was not listed for those native
access function that can emit it.
The order of errors for many functions in glfw3native.h did not match
the order used in glfw3.h.
The documentation for GLFW_PLATFORM_UNAVAILABLE was a little bit terse.
This is primarily a workaround for a GLFW application reading and/or
writing to the clipboard in rapid succession and catching up with the
Windows Clipboard History, which also has to contend for the lock.
Shifted the documentation away from the term 'named keys' as something
different than keys that glfwGetKeyName will return a name for. The
already existing term 'key token' should now be used to refer to the
GLFW_KEY_* constants.
The associated term 'named mouse button' was also replaced with
'supported mouse button'.
The parts explaining which key tokens will return a valid scancode from
glfwGetKeyScancode have hopefully been clarified. This issue was
reported in #2055.
The GLFW_KEY_UNKNOWN constant has been moved out of the list of key
tokens to simplify and hopefully clarify the related documentation.
Various other keyboard key related edits were made, hopefully resulting
in improvements.
Related to #2055
The current wording states that all keys have synthetic key release
events generated after focus is lost, but keys that aren't named
don't have any state held, so no such events are generated for them.
The new wording clarifies that only named keys have the events generated
for them.
This is partly based on the implementation of libdecor support in
PR #1693 by @ christianrauch.
Where available, the libdecor library is loaded at init and becomes the
preferred method for window decorations. On compositors that support
XDG decorations, libdecor in turn uses those. If not, libdecor has
a plug-in archtecture and may load additional libraries to either use
compositor-specific decorations or draw its own.
If necessary, support for libdecor can be disabled with the
GLFW_WAYLAND_LIBDECOR init hint. This is mostly in case some part of
the dynamic loading or duplication of header material added here turns
out to cause problems with future versions of libdecor-0.so.0.
Fixes#1639Closes#1693
Related to #1725
This adds window hints for the initial position, in screen coordinates,
of a window. The special value GLFW_ANY_POSITION means the window
manager will be allowed to position the window.
It is not possible to set window positions on Wayland and GLFW will
always behave as if these hints are set to GLFW_ANY_POSITION.
Fixes#1603Fixes#1747
This adds a window hint string for the xdg_toplevel::app_id, which is
used by desktop environments to connect windows with application icons
and other information. This is similar to the WM_CLASS property on X11.
A few very minor fixes were done by @elmindreda during merge.
Fixes#2121Closes#2122
By default, the glfw3native.h header will include the platform-specific
headers necessary for the return types of GLFW native access functions.
Sometimes it is preferrable to declare those types
This commit adds support for the GLFW_NATIVE_INCLUDE_NONE macro, which
when defined disables the inclusion of all platform-specific headers.
Fixes#1348
This is a follow-up to 535c3ce632.
That commit made glfw3native.h undefine GLAPIENTRY whenever
GLFW_EXPOSE_NATIVE_GLX or GLFW_EXPOSE_NATIVE_OSMESA was defined, on the
assumption that it was glfw3.h that had defined GLAPIENTRY.
If gl.h or an extension loader header has been included before glfw3.h,
then it has defined inclusion guards preventing GLAPIENTRY from being
defined later when the GLX or OSMesa header includes gl.h.
This commit ensures GLAPIENTRY is only undefined if glfw3.h defined it.
Related to #2010
On a Unix system, if you define GLFW_INCLUDE_NONE and
GLFW_EXPOSE_NATIVE_GLX, then include glfw3.h and glfw3native.h, you will
get a redefinition warning for GLAPIENTRY.
The glfw3.h header defines GLAPIENTRY as a service for OpenGL related
headers that assume it's already defined. However, glx.h includes gl.h,
which defines GLAPIENTRY unconditionally.
If not for Hyrum's law, the better solution would have been not to
define GLAPIENTRY if GLFW_INCLUDE_NONE is defined.
Fixes#2010
This docstring previously indicated that GLFW_CONTEXT_REVISION was
a window hint and attribute, but in fact it is only a window attribute
(there is no code which uses this constant in any other context.)
We noticed this in https://github.com/hexops/mach/pull/71/files#r749741814Closes#1992
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
Add GLFW_FORMAT_UNAVAILABLE to the list of possible errors in the
reference documentation for glfwGetClipboardString.
Slightly edited by @elmindreda.
Closes#1998
