This adds the glfwGetGLXFBConfig function for querying the GLXFBConfig
the GLXWindow of a window.
This commit is a squashed and modified version of PR #1925 by knokko.
The following changes were made by elmindreda:
The function signature was changed to handle GLXFBConfig being an opaque
value in core GLX. The function error checks were fixed and updated.
The struct member name was changed. The struct member clearing on
context destruction was removed. All documentation snippets were
updated.
Closes#1925
This adds the glfwGetEGLConfig function for querying the EGLConfig of
the EGLSurface of a window.
This is a re-implementation of the PR #2045 by knokko, slightly
redesigned to handle EGLConfig being an opaque type in core EGL.
Closes#2045
If a modal surface like the window menu was active, clicking on the GLFW
window content area to close it would correctly emit the cursor enter
event but would not propagate the cursor position from the event.
When a click through to the fallback decorations caused the end of
a modal like the window menu, the cursor shape would not be updated
until the next time the cursor moved.
This commit adds an update of the cursor for the pointer enter event for
fallback decoration surfaces, in addition to the updates at pointer
motion events.
The fallback decorations would place the menu at the wrong position, by
not translating the last decoration surface position into toplevel
surface coordinates.
This also limits the menu to the caption area of the top decoration
surface, similar to how other toolkits work.
If fallback decorations were in use, pointer motion over a decoration
surface would cause glfwGetCursorPos to provide incorrect cursor
positions.
The cursor position is now only updated when the pointer is over the
content area of the window, similar to libdecor and XDG decorations.
Windows with keyboard focus may have an active key repeat timer.
This should be reset when the window is closed, or key repeat events
could be sent to a NULL window were it not for the quickfix in PR #2732.
Fixes#2741
Probably the source of #2727
It's increasingly difficult to maintain a safe testing environment for
Windows XP, and so increasingly a burden on contributors to maintain
support for it.
Windows XP has been out of of support since 2014 and should not be used
as a desktop OS.
Fixes#2505
The original MinGW distribution appears to no longer be maintained and
should not be used. Anyone still using MinGW should consider switching
to the MinGW-w64 fork or another actively maintained toolchain.
MinGW-w64 supports 64-bit binaries and provides much newer compilers and
Win32 headers.
Fixes#2540
This commit re-organizes 6e7f93916b96c643ca7abe45d09f72d841ff15ed.
* Load missing XIM related function symbols.
* Generalize platform-specific features to _GLFWplatform.
* Change the defalut input style to over-the-spot style.
* Rename `decodeUTF8()` to `_glfwDecodeUTF8()` to make it as internal API.
* It will be also needed to implment input method for Wayland.
* Refactor code shapes and variable names.
About over-the-spot style and on-the-spot style on X11:
* In over-the-spot mode, almost all APIs are disabled since applications only
need to specify the preedit candidate window position by `glfwSetPreeditCursorPos()`.
* We can change the style by enabling `GLFW_X11_ONTHESPOT` init hint, but it
has the following problems.
* Status APIs don't work because status callbacks don't work.
(at least in my ibus environment).
* Can't specify the candidate window position.
Known problems:
* Some keys (arrow, Enter, BackSpace, ...) are passed to applications during preediting.
* This will be fixed in PR #1972 : https://github.com/glfw/glfw/pull/1972
Co-authored-by: Takuro Ashie <ashie@clear-code.com>
This fix is based on shibukawa's fix:
https://github.com/glfw/glfw/pull/658
The differences is the following.
* Remove `X_HAVE_UTF8_STRING` branching since the current logic doesn't use it
* Replace `XNDestroyCallback` for `XNPreeditAttributes` in `XCreateIC`
Co-authored-by: Yoshiki Shibukawa <yoshiki@shibu.jp>
Co-authored-by: Takuro Ashie <ashie@clear-code.com>
This commit re-organizes 31b12b7f79a5aa8bd8f8eb1488a050ab894ca289.
* Use dynamic load for TIS functions and stop using Carbon.
* Generalize platform-specific features to _GLFWplatform.
* Add caret-position info to preedit-callback.
* Handle UTF16 data correctly.
* Implement `firstRectForCharacterRange:actualRange:` to display preedit candidate window correctly.
* Suppress _glfwInputKey during preediting.
* Ensure preedit cleared after committed.
* Fix wrong length of markedRange.
* Improve IME status APIs.
* Refactor code shapes and variable names.
Co-authored-by: Takuro Ashie <ashie@clear-code.com>
Co-authored-by: xfangfang <2553041586@qq.com>
This fix is based on shibukawa's fix:
https://github.com/glfw/glfw/pull/658d36a164423
Co-authored-by: Yoshiki Shibukawa <yoshiki@shibu.jp>
Co-authored-by: Takuro Ashie <ashie@clear-code.com>
This commit re-organizes 9d9af132610829f295c34ceb81b17af8b567b76f.
* Use dynamic load for Imm32.
* Generalize platform-specific features to _GLFWplatform.
* Add caret-position info to preedit-callback.
* Add cursorWidth to preeditCursor and related APIs.
* Handle UTF16 data correctly.
* Handle GCS_RESULTSTR so that committed texts are processed correctly.
* Handle WM_IME_ENDCOMPOSITION to clear preedit.
* Handle WM_IME_SETCONTEXT.
* https://learn.microsoft.com/en-us/windows/win32/intl/wm-ime-setcontext#remarks
* Refactor code shapes and variable names.
Co-authored-by: Takuro Ashie <ashie@clear-code.com>
This fix is based on shibukawa's fix:
https://github.com/glfw/glfw/pull/658d36a164423
Some minor coding style changes are made, but not yet follow glfw's one,
and some comments doesn't follow recent changes. So further work is
needed.
Co-authored-by: Yoshiki Shibukawa <yoshiki@shibu.jp>
Co-authored-by: Takuro Ashie <ashie@clear-code.com>
If detectEWMH failed to query the EWMH helper window, it would return
without restoring the previous Xlib error handler. This was bad
(because other code might also be using the facility) and bad (because
GLFW would assert the next time it tried to grab the error handler).
This commit adds the necessary release call.
Closes#2593Fixes#2601Closes#2631
libxkbcommon already provides functions to convert keysyms to codepoints
and UTF-8. The library has offered these functions since 0.5.0[1], so
using them won't cause any compatibility problems.
[1] https://xkbcommon.org/doc/0.5.0/group__keysyms.htmlCloses#2444