Bug 411729 - Accented and dead keys do not work when QT_IM_MODULE is set to anything
Summary: Accented and dead keys do not work when QT_IM_MODULE is set to anything
Status: VERIFIED FIXED
Alias: None
Product: kde
Classification: I don't know
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: HI normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL: https://bugreports.qt.io/browse/QTBUG...
Keywords: regression, wayland
: 393907 413256 426621 430526 435686 454570 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-09-08 19:56 UTC by tdyzio
Modified: 2023-08-11 08:54 UTC (History)
38 users (show)

See Also:
Latest Commit:
Version Fixed In: kde/5.15


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tdyzio 2019-09-08 19:56:34 UTC
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
Comment 1 Johann Höchtl 2019-10-27 16:29:53 UTC
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
Comment 2 Patrick Silva 2019-11-01 12:55:54 UTC
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
Comment 3 Jose María Galdós 2020-03-20 04:07:20 UTC
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
Comment 4 Johann Höchtl 2020-03-20 08:10:51 UTC
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?
Comment 5 tdyzio 2020-03-20 14:08:06 UTC
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.
Comment 6 Jose María Galdós 2020-03-20 18:44:19 UTC
It works!

My /etc/environment was empty. After installing ibus, reboot and Spanish accents works flawless.
Comment 7 Johann Höchtl 2020-03-21 10:15:07 UTC
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.
Comment 8 Raul 2020-03-25 16:01:34 UTC
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.
Comment 9 Thiago Sueto 2020-06-22 04:42:43 UTC
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.
Comment 10 tdyzio 2020-06-22 11:53:49 UTC
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.
Comment 11 luancarvalho 2020-08-28 07:05:23 UTC
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
Comment 12 Benjamin Hennion 2020-09-30 15:50:03 UTC
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.
Comment 13 Nate Graham 2020-11-23 17:02:23 UTC
*** Bug 426621 has been marked as a duplicate of this bug. ***
Comment 14 Nate Graham 2020-11-23 17:02:30 UTC
*** Bug 393907 has been marked as a duplicate of this bug. ***
Comment 15 tromzy 2020-11-24 16:52:00 UTC
I am affected by this issue as well, setting "QT_IM_MODULE=" in /etc/environment works around the issue.
Comment 16 tdyzio 2020-11-25 13:52:48 UTC
Tom, thanks so much. This fixed the problem. Both Greek keyboard layouts: Regular and Polytonic work now. Thanks again.
Comment 17 tdyzio 2020-11-25 13:55:56 UTC
Tromzy, My apologies for misspelling your name. Should have paid attention.
Comment 18 Thiago Sueto 2020-12-13 05:45:14 UTC
Apparently, this bug is also reproducible with the new QT_IM_MODULE=plasmaim (the character alternatives thingie).
Comment 19 Bart Ribbers 2021-01-21 13:35:30 UTC
*** Bug 430526 has been marked as a duplicate of this bug. ***
Comment 20 Bart Ribbers 2021-01-21 13:36:39 UTC
*** Bug 413256 has been marked as a duplicate of this bug. ***
Comment 21 geisserml 2021-02-13 12:05:11 UTC
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.
Comment 22 David Marzal 2021-02-20 18:13:01 UTC
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
Comment 23 Gaël de Chalendar (aka Kleag) 2021-03-03 08:03:20 UTC
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.
Comment 24 Vlad Zahorodnii 2021-03-05 11:15:18 UTC
(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?
Comment 25 Vlad Zahorodnii 2021-03-05 11:30:23 UTC
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.
Comment 26 Andrey 2021-03-05 15:21:42 UTC
(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
Comment 27 Nate Graham 2021-03-05 15:46:33 UTC
(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?
Comment 28 Vlad Zahorodnii 2021-03-05 16:05:42 UTC
(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
Comment 29 Nate Graham 2021-03-05 17:34:13 UTC
So this is 100% an upstream issue? Nothing reasonable that we can do on our side?
Comment 30 Luiz Angelo De Luca 2021-03-05 18:07:37 UTC
(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.
Comment 31 Andrey 2021-03-05 22:22:09 UTC
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"
Comment 32 Aleix Pol 2021-03-09 01:39:12 UTC
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.
Comment 33 Aleix Pol 2021-03-10 00:21:31 UTC
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.
Comment 34 Andrey 2021-03-10 01:41:03 UTC
We have
GlobalShortcutsTest::testComponseKey()

any chance the problem can be caught in the unit tests?
Comment 35 Aleix Pol 2021-03-10 01:42:15 UTC
Why would we track a bug in Qt from our tests?
Comment 36 Aleix Pol 2021-04-13 14:29:02 UTC
The fix has been merged both upstream and in the Qt Patch Collection.
https://invent.kde.org/qt/qt/qtwayland/-/merge_requests/4
Comment 37 geisserml 2021-04-13 19:59:50 UTC
Cool, thanks @AleixPol for taking care of this!
Comment 38 Nate Graham 2021-04-13 20:58:13 UTC
*** Bug 435686 has been marked as a duplicate of this bug. ***
Comment 39 papu 2021-06-17 14:00:03 UTC
(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!
Comment 40 Aleix Pol 2021-06-17 14:06:15 UTC
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.
Comment 41 papu 2021-06-17 17:31:03 UTC
(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 ,
Comment 42 quanticcpu2100 2021-12-29 19:10:35 UTC
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
Comment 43 quanticcpu2100 2021-12-29 19:13:16 UTC
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
Comment 44 Nate Graham 2022-01-04 22:05:50 UTC
Can you please file a new bug report for that?
Comment 45 Nate Graham 2022-06-01 19:17:56 UTC
*** Bug 454570 has been marked as a duplicate of this bug. ***
Comment 46 teadrinkingprogrammer 2023-03-07 13:26:38 UTC
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?
Comment 47 Eduardo 2023-04-28 01:41:16 UTC
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
Comment 48 Andrey 2023-04-28 06:51:08 UTC
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?
Comment 49 Eduardo 2023-04-29 16:28:31 UTC
(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
Comment 50 Eduardo 2023-04-29 16:38:26 UTC
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.
Comment 51 Andrey 2023-04-29 16:49:24 UTC
The accented symbols should work without any Input Method, though.
See the reports above.
Comment 52 Eduardo 2023-04-29 17:30:25 UTC
(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.