summaryrefslogtreecommitdiffstats
path: root/src/gui/platform/unix/qxkbcommon.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Hook Qt::Key_Call and Qt::Key_Hangup for xkbMéven Car13 days1-0/+6
| | | | | | | | | As found in laptops, like thinkpads. And Key_Call for directfb. Change-Id: I7858f5c81cff43c1550716e4141eef8209e4794f Reviewed-by: David Edmundson <davidedmundson@kde.org>
* CRA review: gui/platform/unix/*Liang Qi2025-09-251-0/+1
| | | | | | | | | | | | | | | | | | The files that we maintain by hand are marked as significant. * QDBus and QSettings are in used very often in most classes. * D-Bus and QSettings are security critical, but the implementation is merely a user, and does not do any parsing or communication on its own. Notes: * dbusmenu and dbustray sub directories in seperate changes. * qdesktopunixservices_p.h as security critical which just follows qdesktopunixservices.cpp in ad98583911a8252e56648cd2efc748b09b3691f3 QUIP: 23 Task-number: QTBUG-134573 Pick-to: 6.10 6.8 Change-Id: I5cdcaedb1f987a86cf7a16c843ebfe7f0e7238c7 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Add Qt::Key_KeyboardKai Uwe Broulik2025-02-171-0/+1
| | | | | | | | | Adds a "media key" for the "Keyboard settings" key found on some laptops. Change-Id: Id041a551844f095f1d7d2fd25d37346da30407a3 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: David Edmundson <davidedmundson@kde.org>
* qxkbcommon: map XKB_KEY_XF86Calculator to Qt::Key_CalculatorYifan Zhu2024-01-311-0/+1
| | | | | | | | | | | | | cfd935fe6c26800befc10889afc0aebde311acca removed the erroneous mapping from XKB_KEY_XF86Calculator to Qt::Key_Launch1, leaving it unmapped. It should be mapped to Qt::Key_Calculator, just like XKB_KEY_XF86Calculater. Fixes: QTBUG-121713 Pick-to: 6.7 6.6 6.5 Change-Id: Iaa28e38792f43a7950a3c38397869a6ffed332d1 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Liang Qi <liang.qi@qt.io>
* QXkbCommon: Use isKeypad() to replace duplicate logicLu YaNing2023-11-091-1/+1
| | | | | | | | This amends 298c9509129cf039a1da75d5682cbe273a341590 . Pick-to: 6.6 6.5 Change-Id: I44696464817d6d3f6b1b3a7d005334805fb1cc38 Reviewed-by: Liang Qi <liang.qi@qt.io>
* xkb: fix build with libxkbcommon 1.6.0 and laterLiang Qi2023-10-101-0/+4
| | | | | | | | | | | A few XKB_KEY_dead_* defines got removed from 1.6.0. See also https://github.com/xkbcommon/libxkbcommon/blob/6073565903488cb5b9a8d37fdc4a7c2f9d7ad04d/NEWS#L9-L14 https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/merge_requests/70/diffs?commit_id=cb44799b72f611eb4c9d7cc185bc3b09e070be08 Pick-to: 6.6 6.5 6.2 5.15 Fixes: QTBUG-117950 Change-Id: I55861868f2bb29c553d68365fa9b9b6ed01c9aea Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Implement XCB key mapper in terms of QPlatformKeyMapperTor Arne Vestbø2023-10-091-9/+22
| | | | | Change-Id: I81af1200b7b1113062d66a76a185a6d15eab0ba9 Reviewed-by: Liang Qi <liang.qi@qt.io>
* revert "xkbcommon: make shortcuts persistent across layouts"Tor Arne Vestbø2023-09-291-3/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 5e76a9569e37e6620a7ddf3a9d9620fbb9b9d04f. The change's stated goal was to make shortcuts "stable", i.e. work the same, regardless of which keyboard layout the user has selected. In doing so, it changed the semantics of shortcut handling to depend on the order of the keyboard layouts reflected by XKB, picking the first Latin layout in the list, instead of prioritizing the currently selected/active keyboard layout. This change in semantics is a major behavior change, and breaks common and valid setups such as having [en,fr] or [en,de] layouts. For example, the French layout uses an AZERTY layout, where the Q and A keys are switched compared to QWERTY. With the change in place, pressing the physical A key on a French keyboard, with Control pressed, no longer selects all text, but instead quits the application, as the shortcut is interpreted based on the English layout, which just happens to be first in the list. Similar issues exist for German layouts, which use QWERTZ, or more complex layouts such as the Neo layout. The semantics of prioritizing the order of declared layouts instead of the active one is inconsistent with both macOS and Windows, as well as other toolkits on Linux, including GTK and earlier versions of Qt. It's also not discoverable by the user that the order now matters. For example, there is no UX in the Gnome setting that tells the user to ensure the order matches their expectations for shortcut handling. And if there was, this would only apply to Qt apps built with 6.6.0, creating inconsistent behavior for users. Worse, the X server is limited to four concurrent keyboard layouts (groups), so if the user adds more layouts than that, Gnome will replace the X server's view of layouts only when switching to a layout beyond the first four. And in that case, the X server's view of the layouts is actually starting with the fifth layout declared in the Gnome preferences. The logic in the reverted patch does not take this into account, making it confusing for the user which layout actually takes precedence. Note that reverting this change does not affect our fallback logic for layouts that do not produce Latin symbols for the given key press, such as Greek or Russian. Those layouts will continue to fall back to a Latin layout for their QKeyEvent::key(). [ChangeLog][QtGui][X11/Wayland] A change in 6.6.0 that resulted in keyboard shortcuts not respecting the user's active layout has been reverted. Pick-to: 6.6 Task-number: QTBUG-108761 Change-Id: Iec2897cd1541c0c125cc5b1078d0beec12b501c0 Reviewed-by: David Edmundson <davidedmundson@kde.org> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io> Reviewed-by: Liang Qi <liang.qi@qt.io>
* Avoid crash when keysymToQtKey(keysym, Qt::ControlModifier) is calledAlexander Volkov2023-09-281-0/+2
| | | | | | | | For example when Ctrl+Home is sent by virtual keyboard on Wayland. Pick-to: 6.6 6.5 6.2 5.15 Change-Id: I41f1d2a28c9091efa621d5826a3b9e3e0e481ceb Reviewed-by: Liang Qi <liang.qi@qt.io>
* qxkbcommon: Amend comment for Qt::Key upper-case transformationAndrey Butirsky2023-04-201-6/+6
| | | | | | | | | | | | | This should make it clear enough that the issue here is a quirk of Qt::Key and not something otherwise special about case-change affecting whether a character is in Latin-1 (for all that this is the root cause of the quirk in Qt::Key). Pick-to: 6.5 Change-Id: I80fa6b78a0d0c431401a3fea18edf6149de08b92 Reviewed-by: Andrey Butirsky <butirsky@gmail.com> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* QXkbCommon: set Qt::KeypadModifier when keypad button is pressedMario Roessel2023-04-201-1/+4
| | | | | | | | Pick-to: 6.5 Task-number: QTBUG-111503 Done-With: Liang Qi <liang.qi@qt.io> Change-Id: Ic7ca48ea8709d38aa83c95a9b5a7d39ff82f08c7 Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
* xkbcommon: make shortcuts persistent across layoutsAndrey Butirsky2023-01-311-36/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | It can happen the same key has different Latin symbols on different layouts: for example, "`" symbol on English layout, no symbol ("^" dead key) on German and ";" symbol on Czech and Hebrew layouts. This creates a problem as these keys will produce different shortcuts depending on what layout is currently active. This patch makes keys generate the same shortcuts corresponding to the first Latin layout configured in the system, independently of layout actually active. For example, when having settings like: setxkbmap -model pc105 -layout "us,de" -option "grp:alt_shift_toggle" After Alt+Shift, the layout changes to de from us. But Ctrl+"^" still generates Ctrl+` shortcut which is from the first(or default) layout. [ChangeLog][QtGui][QXkbCommon] make keys produce the same shortcuts independently of current layout Fixes: QTBUG-108761 Change-Id: Id204a1609ca731f9c56ed3d32847ca18b94be4a0 Reviewed-by: Liang Qi <liang.qi@qt.io> Reviewed-by: Andrey Butirsky <butirsky@gmail.com>
* Port from qAsConst() to std::as_const()Marc Mutz2022-10-111-2/+2
| | | | | | | | | | | | | | | | We've been requiring C++17 since Qt 6.0, and our qAsConst use finally starts to bother us (QTBUG-99313), so time to port away from it now. Since qAsConst has exactly the same semantics as std::as_const (down to rvalue treatment, constexpr'ness and noexcept'ness), there's really nothing more to it than a global search-and-replace, with manual unstaging of the actual definition and documentation in dist/, src/corelib/doc/ and src/corelib/global/. Task-number: QTBUG-99313 Change-Id: I4c7114444a325ad4e62d0fcbfd347d2bbfb21541 Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
* Use SPDX license identifiersLucie Gérard2022-05-161-38/+2
| | | | | | | | | | | | | Replace the current license disclaimer in files by a SPDX-License-Identifier. Files that have to be modified by hand are modified. License files are organized under LICENSES directory. Task-number: QTBUG-67283 Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* QtGui: replace remaining uses of QLatin1String with QLatin1StringViewSona Kurazyan2022-04-281-1/+1
| | | | | | Task-number: QTBUG-98434 Change-Id: I98c27030c783f968cbf38dc966ce486dc366b302 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Gui: Do not depend on transitive includesFabian Kosmale2022-03-171-0/+1
| | | | | Change-Id: I27321235d9c8428de0cff1e22a618299b9e5a97f Reviewed-by: Marc Mutz <marc.mutz@qt.io>
* qxkbcommon: UCS-4-encode surrogate characters in QKeyEvent::key()Gatis Paeglis2021-12-061-1/+5
| | | | | | | | | Fixes: QTBUG-72776 Pick-to: 6.2 5.15 Done-with: Liang Qi <liang.qi@qt.io> Change-Id: I9d1f4e34527079c3bc460016fe9b953636b4d6cb Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Liang Qi <liang.qi@qt.io>
* gui: Fix typos in source code commentsJonas Kvinge2021-10-121-1/+1
| | | | | | Pick-to: 5.15 6.2 Change-Id: Ie53e5542a8f93856470982939ecd8ec90b323d69 Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
* qxkbcommon: Map Super/Hyper to Meta early enough to have an effectAndrey Butirsky2021-05-251-6/+6
| | | | | | | | | | | Super/Hyper keys are detected during a direct mapping phase, but the function returned before the translation to Meta could take place. Task-number: QTBUG-62102 Pick-to: 5.15 6.0 6.1 Change-Id: I9f7ccfd757fa86dbc648951306deb1b43ccf4167 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Andrey Butirsky <butirsky@gmail.com>
* qxkbcommon: Keep lower case as Qt key when upper case is not in Latin1Andrey Butirsky2021-05-251-0/+8
| | | | | | | | | | | | | Upper-casing a Latin1 character might move it out of Latin1 range, for example U+00B5 MICRO SIGN, which upper-case equivalent is U+039C GREEK CAPITAL LETTER MU. If that's the case, then map the original lower-case character. Fixes: QTBUG-93858 Pick-to: 5.15 6.0 6.1 Change-Id: Ibd86fbb7c70d620c0884015ec1c40aa6351e6320 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Andrey Butirsky <butirsky@gmail.com>
* fix Alt+` shortcut on non-US layoutsAndrey Butirsky2021-04-071-6/+6
| | | | | | | | | | | | | Make it possible for non-letter-keys with Latin 1 symbols (`, !, @ etc.) to participate in shortcuts also, when the keys generate national symbols on non-Latin layout. For example, in Russian layout, "`" key generates cyrillic "ё" letter of national alphabet, so shortcuts with the key should still work regardless of the actual layout. Fixes: QTBUG-90611 Change-Id: Id9a505210ff33a94b82511b88c30ef79f3d03913 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix no mapping for SysReq keyAndrey Butirsky2021-03-251-0/+1
| | | | | | | | | | | | | | | | | XKB_KEY_Sys_Req keysym is currently unmapped to any Qt::Key. Implication of this it is uncapable to participate in any keyboard shortcuts. This patch adds the missing mapping. Detected by testXkb KWin unit test Fixes: QTBUG-92087 Pick-to: 5.15 6.0 6.1 Change-Id: I2440c218e265c5636fc1d2703f14d8bfe033967e Reviewed-by: Andrey Butirsky <butirsky@gmail.com> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Liang Qi <liang.qi@qt.io> Reviewed-by: Aleix Pol Gonzalez <aleixpol@kde.org>
* Fix XCB launch key mappingAllan Sandfeld Jensen2021-01-151-18/+17
| | | | | | | | | | | | | They have been reported wrong since Qt 4, and not fixed for behavior compatibility, fixing it for Qt 6. [ChangeLog][X11] XF86LaunchXX keys have been remapped, so the Qt names and X11 names match, instead of being 2 off. Pick-to: 6.0 Fixes: QTBUG-25261 Change-Id: Ie3a8676439ae3e93a78218c9e7f4443565e84356 Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io>
* Un-special-case macOS in handling of QKeyEvent::nativeScanCode()Tor Arne Vestbø2020-10-061-0/+3
| | | | | | | | | | | | | | | | | | | | | | | In the porting from Qt 4 to Qt 5 an assumption was made in QKeyMapper that the underlying platform implementation needed the native scan code to be able to resolve the possible keymaps for an event. As a result, the macOS platform plugin started sending key events with a fake native scan code of 1, so that it would still be allowed to map key events. Which in turn led to the documentation of QKeyEvent::nativeScanCode() getting an exception for macOS. Let's clean up this by removing the original assumption, and leave it up to the platforms to decide what information from the key event is needed. QKeyMapperPrivate::possibleKeys() will still call extractKeyFromEvent as a fallback if the platform layer doesn't return any possible keys. Change-Id: I122a45bcec658c45ccc0b2c0671eb264d85d7be6 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* Long live QKeyCombination!Giuseppe D'Angelo2020-09-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C++20 via P1120 is deprecating arithmetic operations between unrelated enumeration types, and GCC 10 is already complaining. Hence, these operations might become illegal in C++23 or C++26 at the latest. A case of this that affects Qt is in key combinations: a QKeySequence can be constructed by summing / ORing modifiers and a key, for instance: Qt::CTRL + Qt::Key_A Qt::SHIFT | Qt::CTRL | Qt::Key_G (recommended, see below) The problem is that the modifiers and the key belong to different enumerations (and there's 2 enumerations for the modifier, and one for the key). To solve this: add a dedicated class to represent a combination of keys, and operators between those enumerations to build instances of this class. I would've simply defined operator|, but again docs and pre-existing code use operator+ as well, so added both to at least tackle simple cases (modifier + key). Multiple modifiers create a problem: operator+ between them yields int, not the corresponding flags type (because operator+ is not overloaded for this use case): Qt::CTRL + Qt::SHIFT + Qt::Key_A \__________________/ / int / \______________/ int Not only this loses track of the datatypes involved, but it would also then "add" the key (with NO warnings, now its int + enum, so it's not mixing enums!) and yielding int again. I don't want to special-case this; the point of the class is that int is the wrong datatype. Everything works just fine when using operator| instead: Qt::CTRL | Qt::SHIFT | Qt::Key_A \__________________/ / Qt::Modifiers / \______________/ QKeyCombination So I'm defining operator+ so that the simple cases still work, but also deprecating it. Port some code around Qt to the new class. In certain cases, it's a huge win for clarity. In some others, I've just added the necessary casts to make it still compile without warnings, without attempting refactorings. [ChangeLog][QtCore][QKeyCombination] New class to represent a combination of a key and zero or more modifiers, to be used when defining shortcuts or similar. [ChangeLog][Potentially Source-Incompatible Changes] A keyboard modifier (such as Qt::CTRL, Qt::AltModifier, etc.) should be combined with a key (such as Qt::Key_A, Qt::Key_F1, etc.) by using operator|, not operator+. The result is now an object of type QKeyCombination, that stores the key and the modifiers. Change-Id: I657a3a328232f059023fff69c5031ee31cc91dd6 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* Use QList instead of QVector in gui implementationJarek Kobus2020-07-071-1/+1
| | | | | | | Task-number: QTBUG-84469 Change-Id: I366e845249203d80d640355a7780ac2f91a762f1 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Move xkbcommon to QtGuiFriedemann Kleint2020-07-041-0/+828
Task-number: QTBUG-83255 Change-Id: Ia1c6a49af6be4aaa6b988537c38db3a2c0a646a5 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-16 18:15:13 +0000