The list of compile-time dependencies on FreeBSD lacked evdev-proto.
Unlike on Linux, the input-event-codes.h header file was not implicitly
included on FreeBSD.
Fixes#2445
This was adapted to 3.3-stable from
51920ede6827962ca2fbcad38d1beed1165400af.
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
(cherry picked from commit 9959dc69cadd1f7790060846ffbc44e7da56fc56)
Passing a context-less window to a function that requires a context only
emits a harmless GLFW_NO_WINDOW_CONTEXT error.
(cherry picked from commit 0bd3e879e1fd8c5ed4562929fb0365a5a7089833)
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 was adapted to 3.3-stable from
fbdb53b9ca457ab01675e20d9127cb62d8db88b8.
On systems lacking the EGL_EXT_present_opaque extension, some
compositors treat any buffer with an alpha channel as per-pixel
transparent.
This commit ignores any EGLConfig with an alpha channel if the extension
is missing and the window is created with GLFW_TRANSPARENT_FRAMEBUFFER
set to false.
This is technically not a breaking change since GLFW_ALPHA_BITS is not
a hard constraint, but it is still going to inconvenience anyone using
the framebuffer alpa channel to store other kinds of data.
Related to #1895
(cherry picked from commit ef6c9d8b4f957c2a53374558e393bdb5c4264fa5)
This fixes spelling, grammar and punctuation issues, missing words and
stray words across the documentation. A confusing sentence was removed
from the tutorial.
Closes#2085
(cherry picked from commit 2e12ef00bb4b96c7b4c6ea14f594cc8f50ea718f)
This slightly de-clutters a directory mostly intended for human-readable
documentation.
(cherry picked from commit d3c2121221f7bcd9cce2e164acfbdee8820aec06)
There is a seemingly unavoidable race condition when waiting for data on
the X11 display connection, as long as any other thread is also making
Xlib calls. The event data we are waiting for could be read by the
other thread as part of looking for the reply to its request, before our
poll has begun.
This commit replaces the X11 event sent by glfwPostEmptyEvent with
writing to an unnamed pipe. The race condition remains if other Xlib
calls are made on other threads, but glfwPostEmptyEvent should now be
race-free.
This commit is based on work by pcwalton, OlivierSohn, kovidgoyal and
joaodasilva.
Closes#2033
Related to #379
Related to #1281
Related to #1285
(cherry picked from commit cd22e2849512a88d0ab77bc7a3458646625f2c50)
specified "for linux or unix" and added a bit about using Visual Studio on Windows.
(cherry picked from commit 1a5e07fd4b0a5b6a70e99bbc52470962824d6979)
In the compile guide, the "Dependencies for Linux and OSMesa" section
looks to be one level too high in the hierarchy. I've moved it to be in
line with the similarly-named sub-sub-sections.
Closes#1923.
(cherry picked from commit 52d8347d34b51229cb6029a351ef19cfe60835ca)
Some URLs in the documentation were overlooked during the switch to
https: for the GLFW website. This updates those and a few third-party
URLs.
(cherry picked from commit 787295b3aff950abd45bee3495ac1200eb6bc5e1)
The `#glfw` IRC channel is moving to the Libera.Chat network due to the
recent takeover of the Freenode network.
(cherry picked from commit 78380c7761043b0e4ab1190e3cccbe4d94359aa6)
New code should use GL_KHR_debug instead but it's not as good an example
to use in this case as the symbols it adds has no suffixes.
(cherry picked from commit ec621a00bd96cbc41a7e1f630adf155ae2d08267)
This makes USE_MSVC_RUNTIME_LIBRARY_DLL update the directory scope
CMAKE_MSVC_RUNTIME_LIBRARY variable instead of CMAKE_C_FLAGS on CMake
3.15 and later.
Solution proposed by @moritz-h.
Fixes#1783.
Closes#1796.
(cherry picked from commit f4a73296049b432720c9b6c230e479f9b41d74d3)
Most of this file is indented with tabs but parts are indented with spaces.
Closes#1770.
(cherry picked from commit 58df92acad5ec924274b3c33d277279475a6a645)
On Windows 7, when GLFW framebuffer transparency and the DWM are enabled
but DWM transparency is disabled (i.e. when the Transparency setting is
disabled under Personalization > Color), the contents of the framebuffer
is combined with the last frame using additive blending instead of
replacing the previous contents.
This commit limits GLFW framebuffer transparency on Windows 7 to when
DWM transparency is enabled, removing the previous workaround of setting
a layered window color key that led to rendering artifacts.
Fixes#1512.
(cherry picked from commit 05dd2fa2986c37e7aee3cba917b1d02a3a189390)
Re-worded documentation for the `GLFW_OPENGL_DEBUG_CONTEXT` window hint
to avoid implying that it only applies to OpenGL contexts. Added a link
to the relevant Khronos extension description.
Closes#1720.
(cherry picked from commit 8a69a0d7e545a88de3dd88710e4a881932ca07ed)
The documentation claims that any extension loader library header
included before the GLFW one will prevent the inclusion of the
default OpenGL header. In reality this only worked if the loader
defined the canonical desktop OpenGL __gl_h_ inclusion guard and even
then relied on the OpenGL header to detect this.
This is the companion to 105cf32e0b05e207d4cd5efa462887569ca2116a, which
added the preprocessor logic to check for many known OpenGL and OpenGL
ES inclusion guards and not even attempt to include the default header
if any are present.
Some clarification of the language around header inclusion has also been
attempted, including making GLFW_INCLUDE_NONE more prominent.
Fixes#1695.
(cherry picked from commit 399c2a1fadbe6a1019c54f63d3839ef97a77d783)
