SUMMARY The problem is not only associated with Dolphin, it shows up in other applications like Open Office, Konsole. Basically any place where you enter words. STEPS TO REPRODUCE 1. Select Greek keyboard (Normal or Polytonic) in Regional settings. 2. click on the Greek flag. 3. Start Dolphin, create new say Folder or try to edit file name type say ";ι" which should give you "ί" (it works here, interestingly). OBSERVED RESULT no dead key is functional. EXPECTED RESULT I showed it above. Point of notice: work fine in clawsmail and thunderbird Example from thunderbird and polytonic keyboard ι ί ω ώ ὼ ὡ ώ ὠ ώ ὠ ὡ ὼ ῳ ῶ This suggests to me that KDE basically provides the keyboards correctly to some applications, but it does not to some other. I must also say that they worked fine before, but I did not notice when they stopped working, since I used Greek keyboard mostly for emailing. Before I was able to type Greek accented filenames in dolphin, but not today. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Debian Stable, Konsole 18.04.0 KDE Plasma Version: plasma-desktop 4:5.14.5.1-1 KDE Frameworks Version: 5.54.0-1 ? Qt Version: 5.11.3+dfsg1-1 ? ADDITIONAL INFORMATION
I am adding to this bug as I am relatively certain, that I am affected by the same bug. Using Manjaro Operating System: Manjaro Linux KDE Plasma Version: 5.16.5 KDE Frameworks Version: 5.62.0 Qt Version: 5.13.1 Kernel Version: 5.3.6-1-MANJARO under Wayland. My locale says: localectl System Locale: LANG=en_US.UTF-8 LC_NUMERIC=de_AT.UTF-8 LC_TIME=de_AT.UTF-8 LC_MONETARY=de_AT.UTF-8 LC_PAPER=de_AT.UTF-8 LC_NAME=de_AT.UTF-8 LC_ADDRESS=de_AT.UTF-8 LC_TELEPHONE=de_AT.UTF-8 LC_MEASUREMENT=de_AT.UTF-8 LC_IDENTIFICATION=de_AT.UTF-8 VC Keymap: de-latin1 X11 Layout: de X11 Model: pc105 X11 Options: terminate:ctrl_alt_bksp When I try to enter dead keys under that layout like é (´ followeg by the letter e) or ê (^ followed by the letter e) in native KDE applications, these letters get ignored. Strangely, they are also ignored in OpenOffice. Dead letter entry works in GTK-Applications like firefox or thunderbird. They also work at the console. May be related to #411729 ? This is NOT exclusive to Dolphin, therefore re-assigning to frameworks-wayland
Same problem on Neon unstable edition. Dead keys work with Xwayland apps, but they don't with apps running natively on Wayland. Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.17.80 KDE Frameworks Version: 5.64.0 Qt Version: 5.13.1 $localectl System Locale: LANG=pt_BR.UTF-8 VC Keymap: br-abnt2 X11 Layout: br X11 Model: pc105
Same problem in Spanish tilde keys (áéíóú). Only affects Wayland, Xwayland applications work correctly. Operating System: Manjaro Linux KDE Plasma Version: 5.18.3 KDE Frameworks Version: 5.67.0 Qt Version: 5.14.1 Kernel Version: 5.5.8-1-MANJARO Window System: Wayland Locale: System Locale: LANG=es_MX.UTF-8 LC_TIME=es_ES.UTF-8 VC Keymap: us-acentos X11 Layout: us X11 Model: pc105 X11 Variant: intl
try to add this to /etc/environment INPUT_METHOD=ibus GTK_IM_MODULE=ibus QT_IM_MODULE=ibus XMODIFIERS=@im=ibus Do accents work afterwards?
Johann, First of all I never before had to use ibus. I never had it installed on my system. Having said that, I did install number of ibus packages. As to /etc/environment: I am not sure debian is using it in buster. Mine has always been empty. Anyway, I looked around and I also messed with ~/.bashrc. Interesting thing though is that after I run ibus-setup EL ibus flag (actually I could see three selections for my choice languages) showed up, my regular keyboard flags (4)stopped working but my accents still did not work. I may be still missing something, but I am not sure ibus is the way to go, since I never had to use it before. I'll keep it for a while to see if I can get it to workit will work.
It works! My /etc/environment was empty. After installing ibus, reboot and Spanish accents works flawless.
As I see it right now, for those where installing ibus and adding the env variables to /etc/environment (PAM) works, it is a packing / distribution issue. Whether this IS the actual solution OR has to been tackled otherwise has to be decided from a Plasma architectural perspective. Gnome is not affected as the ibus setting is assumed, even in absence of the set environment variables, KDE doesn't implement the fallback. BTW. currently emerges another (more modern?) approach to let system.d set these variables on a per-user session, but this is a different topic.
I can confirm Johann Höchtl's workaround fixes this annoying behavior in Gentoo + Plasma + Wayland, Spanish language. Thanks a lot! Surprisingly, I've got this other PC with Arch + Plasma + Wayland and dead keys have been working fine from the beginning.
Telegram (from the website with this fix: https://github.com/telegramdesktop/tdesktop/issues/7944) and Firefox recognize dead keys correctly. However, Firefox seems to do its own thing regarding input (if you notice, it's the only application on Plasma that accepts Ctrl+Shift+U Unicode input), and the fix I found out for Telegram doesn't work when set for the entire desktop. What's interesting however is that the same fix of using ibus works for Telegram (from repos, website, snap and flatpak), as can be seen in https://github.com/telegramdesktop/tdesktop/issues/1041. Is this perhaps a Qt issue? While writing this comment I found another workaround/fix: set QT_IM_MODULE. Even if it's blank. I just noticed that if I run kate, dead keys aren't recognized, but if I run QT_IM_MODULE= kate or QT_IM_MODULE=xim kate, it works. Actually it regardless of whatever I put in it for some reason, like QT_IM_MODULE=lmao kate. Can anyone reproduce this? If this works, this would be preferable over installing a different input method IMO.
I did try this method and it sort of worked. The problem with this method is as follows: 1. I lost my polytonic keyboard selection (have two keyboard selections modern and polytonic). 2. Apps that worked before like browsers and claws-mail stopped working as should. But, I must admit that I could accent my file names in dolphin. Accents started to work in Kate and LibrOffice, but the behavior was not quite as I would expect it to be. So, the final conclusion is I am back to my normal keyboard selections and I work around, by writing words in claws-mail and then pasting them into Dolphin, LibreOffice or Kate. It sucks, but it's a work around until QT guys really fix it. I wonder why is this problem ignored.
I am affected using Plasma 5.19.4 and Qt 5.14.2. Setting QT_IM_MODULE="" works for me. Is this indeed a Qt bug? Is there a Qt bug report for this? === System info === Operating System: Kubuntu 20.10 KDE Plasma Version: 5.19.4 KDE Frameworks Version: 5.73.0 Qt Version: 5.14.2 Kernel Version: 5.8.0-16-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i5-1035G1 CPU @ 1.00GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics
Hello, I am affected too, and the workaround QT_IM_MODULE='' is no good for me as it disables the virtual keyboard (that I use sometimes on a convertible laptop). I just posted a Qt bug report https://bugreports.qt.io/browse/QTBUG-87088, in case you want to follow its resolution.
*** Bug 426621 has been marked as a duplicate of this bug. ***
*** Bug 393907 has been marked as a duplicate of this bug. ***
I am affected by this issue as well, setting "QT_IM_MODULE=" in /etc/environment works around the issue.
Tom, thanks so much. This fixed the problem. Both Greek keyboard layouts: Regular and Polytonic work now. Thanks again.
Tromzy, My apologies for misspelling your name. Should have paid attention.
Apparently, this bug is also reproducible with the new QT_IM_MODULE=plasmaim (the character alternatives thingie).
*** Bug 430526 has been marked as a duplicate of this bug. ***
*** Bug 413256 has been marked as a duplicate of this bug. ***
Johann Höchtel's fix works for me, many many thanks ;) ! Since I'm pretty reliant on compose and dead key input methods, I wouldn't be able to use Wayland otherwise.
Hi, in case someone find this useful, this also works for me. NO ibus package installed, just: pacman -Qs ibus local/libibus 1.5.23+3+gaa558de8-3 QT_IM_MODULE=ibus or just QT_IM_MODULE= in /etc/environment. both are valid workarounds. Operating System: ArchLinux KDE Plasma Version: 5.21.0 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 Kernel Version: 5.10.17-hardened localectl System Locale: LANG=es_ES.UTF-8 VC Keymap: es X11 Layout: es X11 Model: logitech_g15
Same problem here. The workaround of setting QT_IM_MODULE= in /etc/environment works also. localectl System Locale: LANG=fr_FR.UTF-8 VC Keymap: n/a X11 Layout: fr X11 Model: pc105 X11 Variant: latin9 KDE Neon up to date KDE Frameworks 5.79.0 Qt 5.15.2 (construit sur 5.15.2) Le système de fenêtres wayland I have two keyboard settings in KDE (fr standard and fr bépo) and both behave the same.
(In reply to luancarvalho from comment #11) > I am affected using Plasma 5.19.4 and Qt 5.14.2. Setting QT_IM_MODULE="" > works for me. Is this indeed a Qt bug? Is there a Qt bug report for this? Yes, it seems like a Qt bug. Neither GTK nor applications running via Xwayland have this bug. Can somebody please file a Qt bug report and post the link here?
Based on some QtWayland source code, it seems like it's fully intentional. One need to set QT_IM_MODULE=compose to make Compose key work on Wayland. Odd.
(In reply to Vlad Zahorodnii from comment #24) > Can somebody please file a Qt bug report and post the link here? It seems was posted already above: https://bugreports.qt.io/browse/QTBUG-87088
(In reply to Vlad Zahorodnii from comment #25) > Based on some QtWayland source code, it seems like it's fully intentional. > One need to set QT_IM_MODULE=compose to make Compose key work on Wayland. > Odd. Just compose key support, or all dead keys?
(In reply to Nate Graham from comment #27) > (In reply to Vlad Zahorodnii from comment #25) > > Based on some QtWayland source code, it seems like it's fully intentional. > > One need to set QT_IM_MODULE=compose to make Compose key work on Wayland. > > Odd. > Just compose key support, or all dead keys? compose key and dead keys
So this is 100% an upstream issue? Nothing reasonable that we can do on our side?
(In reply to Nate Graham from comment #29) > So this is 100% an upstream issue? Nothing reasonable that we can do on our > side? Most affected software will run in KDE. It should be in KDE interest to do something, specially when there is the increasing focus on wayland. From the user perspective, KDE is the one asking to use a broken setup, no matter who wrote the code. If there is some form of workaround and KDE is also responsible to setup the user environment, KDE should do it instead of expecting (thousands of) users or (dozens of) distributions to do it.
Could it be related to this? client: rework input method handling: https://codereview.qt-project.org/c/qt/qtwayland/+/248181 If so, the bug can be on our side: "Some users might mistakenly think that this patch introduces a regression with Qt on KDE, but it is actually a KWin/Wayland compositor bug: https://bugs.kde.org/show_bug.cgi?id=405388"
So I looked a bit into the issue because I find it very frustrating. Here's what happened: 1. it didn't work 2. Johan@Qt added the composite support: https://codereview.qt-project.org/c/qt/qtwayland/+/211478 This worked like we expect to, at least to some extent since Johan@Qt did mention there was some TODOs. 3. Gatis@Qt created a task that basically reverted Johan@Qt's work because there was too much duplicated code (?). He created an issue in their bug tracking system and then he "fixed it". https://bugreports.qt.io/browse/QTBUG-65503 https://codereview.qt-project.org/c/qt/qtwayland/+/248181 --- To understand his suggestion we need to see how this is implemented in Qt: There's two QT_IM_MODULEs at play here: QComposeInputContext (compose, in QtBase) and QWaylandTextInput. They both inherit QPlatformInputContext. QComposeInputContext is a small module that filters inputs and when there's a compose key, it records it and filters the next one if it applies. QWaylandTextInput is an implementation of the text-input-v2 protocol. This one is what we use for talking to virtual keyboards. As far as I understood, Gatis@Qt stance was that supporting both composition and virtual keyboards at the same time is wrong for a series of things (see his gerrit MR). His solution was to just remove composition and then blame KDE for not supporting it in a different way: https://bugs.kde.org/show_bug.cgi?id=405388 The different way he suggests is, if I understand correctly, that we activate and deactivate the text_input_v2 offer depending on whether we have a running keyboard: If there's a virtual keyboard offer, then kwin announces text_input_v2, then the clients use QWaylandTextInput. When kwin considers that a keyboard is what makes sense, it unregisters text_input_v2 and Qt clients all switch to QComposeInputContext. It's worth noting that the fact that these work at all on weston/sway/gnome is pure chance: Qt implements a non-standard text input protocol so it always falls back to QComposeInputContext. --- My opinion and a plan: I don't think that registering and unregistering will solve much and it feels like we are workarounding a limitation from the compositor. In the end it's Qt clients behaving weird exclusively (weston-terminal or gedit work just fine). That said, Gatis@Qt did have some concerns with how it was implemented and I don't think he was entirely wrong about these. I have the feeling that moving the composition implementation from QWaylandInputDevice where Johan@Qt initially implemented it to QWaylandTextInput (by copying some QComposeInputContext code I guess) would work and allow us to move past this weird situation. We wouldn't have though the problem of input methods fighting one another since we'd already be in one of the implementations. I'll think about it a bit further and see if I can just implement something to get us out of this situation.
This is my promised fix: https://codereview.qt-project.org/c/qt/qtwayland/+/338196 Works fine for me, still need to see what Qt devs think about it.
We have GlobalShortcutsTest::testComponseKey() any chance the problem can be caught in the unit tests?
Why would we track a bug in Qt from our tests?
The fix has been merged both upstream and in the Qt Patch Collection. https://invent.kde.org/qt/qt/qtwayland/-/merge_requests/4
Cool, thanks @AleixPol for taking care of this!
*** Bug 435686 has been marked as a duplicate of this bug. ***
(In reply to Aleix Pol from comment #33) > This is my promised fix: > https://codereview.qt-project.org/c/qt/qtwayland/+/338196 > > Works fine for me, still need to see what Qt devs think about it. hola, bon dia Aleix :) this is not revolved for me, programs like steam, firefox, thunderbird, visual studio code, gvim, skype, jdownloader the acented àáäâ is working, also is working well on ttys; but not in libreoffice, telegram and in all plasma infrastructure programs where i can't use the acented keys. gnu/linux: gentoo ~amd64 keyboard model: generic 104-key pc map: es spanish catalan (spain , with middle-dot L) kde plasma: 5.22.1 frameworks: 5.83.0 qt: 5.15.2 keymap=u -es consolefont=lat9w-16 sorry for my bad english! thanks a lot!
Bon dia, papu. The issue sure is fixed. Make sure you are building Qt with the following commit 91c48320633e493b4cd519e5d73b836a878b2b77, it's not part of Qt 5.15 but our patch collection. There's nothing else we can do from KDE to fix this anyway.
(In reply to Aleix Pol from comment #40) > Bon dia, papu. > > The issue sure is fixed. Make sure you are building Qt with the following > commit 91c48320633e493b4cd519e5d73b836a878b2b77, it's not part of Qt 5.15 > but our patch collection. > > There's nothing else we can do from KDE to fix this anyway. molt be amic meu! :) https://invent.kde.org/qt/qt/qtwayland/-/commit/91c48320633e493b4cd519e5d73b836a878b2b77.patch i was dificult for me to find this code , on gentoo is easy to patches the code :) thanks so much! i use this on gentoo and it works ,
There is some problem in the system when the user chooses the default language for example: Brazilian Portuguese. If changing the system to the new language affects the keyboard settings by losing the accent of the keys, which is not expected to happen, it would be expected to leave the keyboard options unchanged. To overcome this it was necessary to leave the system in English to work the accent, I don't know if there is another solution. ❯ cat plasma-localerc [Formats] LANG=en_US.UTF-8 LC_TIME=pt_BR.UTF-8 useDetailed=true [Translations] LANGUAGE=en_US:pt_BR This way the system stays in English with 24h time and does not affect the accentuation of the keys. Note: In the keyboard options there is no layout added, with or without layout happens the same problem. Operating System: Fedora Linux 35 KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.89.0 Qt Version: 5.15.2 Kernel Version: 5.15.11-200.fc35.x86_64 (64-bit) Graphics Platform: Wayland
Can you please file a new bug report for that?
*** Bug 454570 has been marked as a duplicate of this bug. ***
The problem seems to have come back for me: for both Xorg and Wayland, setting the environment variable to 'QT_IM_MODULE=' does not work. I have a machine where I have applied this fix and it worked, but now the bug is back. Should I file a new bug report or should this one be opened again?
Had this problem on Wayland Fedora37 some weeks ago, then fixed it with QT_IM_MODULE=ibus. One day I changed to X11 and the problem reappeared, but then vanished again when I went back to Wayland. Now I just updated to Fedora 38 (Wayland), and the issue came back, even with QT_IM_MODULE=ibus. Interesting notes: - When I launch e.g. Konsole from the launcher, I cannot type the dead keys ~´` - If I launch Konsole from itself, by running "konsole", it suddenly works - I recorded the output of `env` for both cases above and got the following diff (which I don't see anything wrong): 26c26 < KONSOLE_DBUS_SERVICE=:1.97 --- > KONSOLE_DBUS_SERVICE=:1.98 35a36 > LESS=-R 37a39 > LSCOLORS=Gxfxcxdxbxegedabagacad 41a44 > PAGER=less 56c59,60 < SHELL_SESSION_ID=458ac8224e6f49fba96d12b85f056764 --- > SHELL_SESSION_ID=9001639909854c029a48343daeac455d > SHLVL=2 84d87 < SHLVL=1 86,89d88 < PAGER=less < LESS=-R < LSCOLORS=Gxfxcxdxbxegedabagacad < LC_ALL=en_US.UTF-8 90a90 > LC_ALL=en_US.UTF-8
Please make sure you have no ibus daemons/packages. Search this report about ibus. Then retest all the env/platform combinations possible. Also, what languages do you have configured, what order?
(In reply to Andrey from comment #48) > Please make sure you have no ibus daemons/packages. Search this report about > ibus. > Then retest all the env/platform combinations possible. I'm not running any process/daemon containing the keyword "ibus" (although there are some packages installed). I thought ibus was the solution, is it not? First time I solved this issue by changing from xim to ibus in the QT environment variable. I still don't get why the application would behave differently with mostly the same environment. > Also, what languages do you have configured, what order? Initially I had installed Fedora 37 in Brazilian Portuguese, but soon I changed it to American English alone. My current locale is: LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=en_US.UTF-8
Found a solution! 1. Launch the Input Method Selector 2. Select IBus (I'm on Wayland) and Logout Somehow mine was set to "No Input Method" after the upgrade.
The accented symbols should work without any Input Method, though. See the reports above.
(In reply to Andrey from comment #51) > The accented symbols should work without any Input Method, though. > See the reports above. Before finding the solution, I tried to set QT_IM_MODULE to an empty string in /etc/environment, without success after restarting the session. After selecting the ibus as input method on the GUI, then QT_IM_MODULE has been redefined to "ibus" somewhere, and everything seems to be working fine now.