Created attachment 159306 [details] Accent "preview" in Firefox SUMMARY When accent keys ("^", "¨", etc.) are pressed, the accent is not displayed (for ex. underlined like in Firefox, see screenshot) in KDE apps (Dolphin (search and rename), Settings (search), Kate, etc.). STEPS TO REPRODUCE 1. Open Kickoff 2. Press any character key 3. Press (once) an accent key OBSERVED RESULT The first character is display, not followed by the accent. Also, pressing the accent then any character that cannot be accented dismisses the accent. EXPECTED RESULT The accent should always displayed, underlined (or with a coloured background) if pressed one, as a character if pressed twice ("^", "¨"), or as accented character with a "compatible" character pressed after (ex. "â", "ü"), or before a not "compatible" character ("^p", "¨3") SOFTWARE/OS VERSIONS Linux/KDE Plasma: Neon Live (20230504-0714) (available in About System) KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 Tested in Wayland Tested with a Azerty keyboard (and a matching keyboard layout configured)
This might require Qt changes to support it. Not sure we can inject this ourselves in KDE. Does this work *anywhere* in *any* piece of KDE software, such as Dolphin, Discover, Kate, Konsole, or Gwenview? Or do they all lack the requested feature?
I've tested on Dolphin, Gwenview, Kate (and Kwrite), Konsole, and all places on KDE settings/applets and file picker, the accents never appear after pressing an accent key once. I've also tested on KDE apps like Dolphin, Gwenview and Kate on Xfce (4.18), with the same result (accent not showing after a single key press). (In Krita, "^" and "¨" keys are simply ignored in all settings fields, it's not possible to entre "â" or "ü" with my current keyboard layout.) On Gnome apps (tested with Geany and Boxes) and Xfce apps (Thunar, etc.) on KDE, it works as expected, the pressed accent is underlined (just like in the attached Firefox screenshot, since, I imagine, Firefox uses Gtk). So it appears that it's only KDE/Qt apps that don't show accent after a single accent key press.
It sounds to me like this isn't a bug, but rather a feature that hasn't been implemented in Qt the way it exists in GTK. KDE software uses Qt for its UI elements, including text fields, so I would recommend that you suggest the feature for implementation at https://bugreports.qt.io. Thanks!
I continue to investigate this, but I found a Qt ticket (https://bugreports.qt.io/browse/QTBUG-79216) that explains that "Qt only generates keyReleaseEvent() for dead keys", confirming that it's on Qt side. Testing with xev show "correctly" (if I understand the output correctly) that press and release events are generated on a single press. Pressing "a" gives: > KeyPress event, serial 39, synthetic NO, window 0x1200001, > root 0x3c9, subw 0x0, time 17983802, (86,0), root:(219,356), > state 0x0, keycode 24 (keysym 0x61, a), same_screen YES, > XLookupString gives 1 bytes: (61) "a" > XmbLookupString gives 1 bytes: (61) "a" > XFilterEvent returns: False > KeyRelease event, serial 39, synthetic NO, window 0x1200001, > root 0x3c9, subw 0x0, time 17983857, (86,0), root:(219,356), > state 0x0, keycode 24 (keysym 0x61, a), same_screen YES, > XLookupString gives 1 bytes: (61) "a" > XFilterEvent returns: False And pressing accent key (aka dead key) "^" also gives two events: > KeyPress event, serial 39, synthetic NO, window 0x1200001, > root 0x3c9, subw 0x0, time 17985745, (86,0), root:(219,356), > state 0x0, keycode 34 (keysym 0xfe52, dead_circumflex), same_screen YES, > XLookupString gives 1 bytes: (5e) "^" > XmbLookupString gives 0 bytes: > XFilterEvent returns: True > KeyRelease event, serial 39, synthetic NO, window 0x1200001, > root 0x3c9, subw 0x0, time 17985793, (86,0), root:(219,356), > state 0x0, keycode 34 (keysym 0xfe52, dead_circumflex), same_screen YES, > XLookupString gives 1 bytes: (5e) "^" > XFilterEvent returns: False So I seems like Qt ignores the dead key (as not a "real" key event) before merging it with next character (certainly to lookup if the accent + character is a valid and so, a single character, or not valid and outputs two characters), but I need more investigation to understand where exactly the event is "lost", if may be recoverable or not by KDE, or if Qt prevents it completely (since Qt team don't seem to change this behaviour, and so, I will close this ticket). The consequence of this may not only be visual, like in the case for this ticket: https://bugs.kde.org/show_bug.cgi?id=464822