Hello,
I’m having trouble typing accents (e.g., é, à, í…). They work fine in Firefox, OnlyOffice, and Discord, but not in ZapZap. Is this a bug, or is there a setting I need to enable?
zapzap does not appear to be a fedora package for f42. From what source did you obtain and install it?
It appears it may be either a copr or github package.
As such you would need to contact the provider with problems.
I am running ZapZap 6.0 Flatpak on F41 KDE and I can type accented characters in ZapZap just fine. (Because my keyboard layout is de in the deadgraveacute variant, I need to type the accent followed by the character to be accented. Just like any other application.) Did it work for you on F41?
FYI, I originally installed the system with the German keyboard layout and I never needed to configure any application specifically, incluing ZapZap.
@computersavvy ZapZap is a flatpack package, I installed it using the Discover app.
@l-c-g I tried running the KDE F41 live from a USB stick, and the results were worse. Even after applying the Catalan layout, it had no effect neither on the test box in the config window, nor in any app.
In KDE F42 I have noticed that not only ZapZap is affected, but also KWrite, Kontact and LibreOffice do not allow typing the accents.
I just tried it with the Catalan layout (really fun since my keys show the German layout and I am not familiar with the Catalan layout). Looking at the preview in KDE’s settings, I tried the key to the right of P (because it looked like a grave accent ` in the preview) and sure enough, when I followed it with an e, it produced è:
The same key with Shift (circumflex ^ in the preview) followed by e produced ê (I did not capture that in the screenshot, though, and I did not want to redo the screenshot and the redacted part).
Weird. But I think that rules out ZapZap as the problem. What do these applications have in common?
Live ISOs seem to be restricted in their ability to do localisation. When I was trying out the F41 live ISO, I found that keyboard layout switching didn’t work properly. (The preview screen did work, like @l-c-g found, but I couldn’t actually switch to the layout to use it in an application.)
But I didn’t have any such problem on the installed version of F41: switching keyboard layouts and typing accented characters works fine (including in Zapzap).
Are you using F42 from the live ISO or from a full install?
@l-c-g thank you very much for spending time testing this. I have recorded a video about what happens on my laptop: https://www.youtube.com/watch?v=df1HhH9fSGE
I believe that it could be because Kwrite and ZapZap use Qt, while Firefox and Element might be using GTK.
@pg-tips I was not aware that live ISOs were worse at handling localisation. I’m using KDE F42 from a full install.
It is hard to see what the letters on-screen are. And the fact that I am not familiar with a Catalan keyboard layout and what should be happening makes it even harder, sorry.
For me, composing characters with diacritics works in both Qt and GTK applications as well as those based on HTML/CSS/Js (i.e., Electron/Tauri) like VS Code, Bitwarden, Element, RustDesk etc. And it behaves the same way in all of them: when I type a dead key like ´, it is shown as an underlined diacritic and I can either repeat it to get the diacritic itself (e.g., to get the backtick for inline code blocks in Markdown or here) or I can type another character like e to get é.
But I agree, I think your best bet is to systematically collect in which applications it works on your system and in which it does not and then figure out what the applications in each group have in common.
I can imagine it is hard to see, the image quality is not the best. Ideally I should have recorded my screen symultaneously, and later on edit the video to display both the screen recording and the other footage at the same time. However, I don’t think I would have illustrated the problem any better, as it is quite simple to express in words: the accent dead key works in some programs and not in others.
Following your recommendation I have tested the most relevant programs I have installed in my computer.
Accents work in these programs:
- Firefox
- Element
- Discord
- Bitwarden
- OnlyOffice
Accents don’t work in these programs:
- ZapZap
- KWrite
- Dolphin
- Plasma Discover
- KDE System Settings
- KDE Application Launcher
- KHelpCenter
- KInfocenter
- LibreOffice (Math, Calc, Draw, Impress, Writer)
- KolourPaint
- Akregator
- KMail
- NeoChat
Hmmm, AFAICS, the working ones are all applications that render HTML/CSS and do not rely on Qt or GTK as a toolkit. The broken ones are Qt apps (including ZapZap, which uses PyQt6 + PyQt6-WebEngine) or use Qt/GTK (LibreOffice).
I suspect this might be an issue in your locale configuration, which leads to problems with libxkbcommon, which is used by Qt/GTK/Kwin/etc. What is the output of the following commands when you run them in a shell (i.e., Konsole, KDE’s terminal emulator):
locale
localectl
localectl list-locales
Good morning Lars, thank you for finding the common denominator to this issue.
I have run the commands in the shell and this is the output:
davidct@fedora:~$ locale
LANG=ca_ES.UTF-8@valencia
LC_CTYPE="ca_ES.UTF-8@valencia"
LC_NUMERIC="ca_ES.UTF-8@valencia"
LC_TIME="ca_ES.UTF-8@valencia"
LC_COLLATE="ca_ES.UTF-8@valencia"
LC_MONETARY="ca_ES.UTF-8@valencia"
LC_MESSAGES="ca_ES.UTF-8@valencia"
LC_PAPER="ca_ES.UTF-8@valencia"
LC_NAME="ca_ES.UTF-8@valencia"
LC_ADDRESS="ca_ES.UTF-8@valencia"
LC_TELEPHONE="ca_ES.UTF-8@valencia"
LC_MEASUREMENT="ca_ES.UTF-8@valencia"
LC_IDENTIFICATION="ca_ES.UTF-8@valencia"
LC_ALL=
davidct@fedora:~$ localectl
System Locale: LANG=ca_ES.UTF-8@valencia
VC Keymap: es-cat
X11 Layout: es
X11 Model: pc105
X11 Variant: cat
davidct@fedora:~$ localectl list-locales
C.UTF-8
aa_DJ.UTF-8
aa_ER.UTF-8
aa_ET.UTF-8
af_ZA.UTF-8
agr_PE.UTF-8
ak_GH.UTF-8
am_ET.UTF-8
an_ES.UTF-8
anp_IN.UTF-8
ar_AE.UTF-8
ar_BH.UTF-8
ar_DZ.UTF-8
ar_EG.UTF-8
ar_IN.UTF-8
ar_IQ.UTF-8
ar_JO.UTF-8
ar_KW.UTF-8
ar_LB.UTF-8
ar_LY.UTF-8
ar_MA.UTF-8
ar_OM.UTF-8
ar_QA.UTF-8
ar_SA.UTF-8
ar_SD.UTF-8
ar_SS.UTF-8
ar_SY.UTF-8
I hope it helps to narrow down the root cause.
There is nothing that immediately jumps out, except that the list of locales is cut off and it does not show the interesting bit, whether the ca_ES ones actually exist.
Can you please post the output of localectl list-locales | grep ca_ES?
On my F41 system, I have two, including the Valencia one.
$ localectl list-locales | grep ca_ES
ca_ES.UTF-8
ca_ES.UTF-8@valencia
Oh, and one more thing, are you in a Wayland session (default) or in an X11 one?
Ah, yes, you are right about the list of locales being cut off. I hadn’t realized than it is longer than what the terminal displays, and that I had to press enter to display more lines. Here it is the complete list:
davidct@fedora:~$ localectl list-locales
C.UTF-8
aa_DJ.UTF-8
aa_ER.UTF-8
aa_ET.UTF-8
af_ZA.UTF-8
agr_PE.UTF-8
ak_GH.UTF-8
am_ET.UTF-8
an_ES.UTF-8
anp_IN.UTF-8
ar_AE.UTF-8
ar_BH.UTF-8
ar_DZ.UTF-8
ar_EG.UTF-8
ar_IN.UTF-8
ar_IQ.UTF-8
ar_JO.UTF-8
ar_KW.UTF-8
ar_LB.UTF-8
ar_LY.UTF-8
ar_MA.UTF-8
ar_OM.UTF-8
ar_QA.UTF-8
ar_SA.UTF-8
ar_SD.UTF-8
ar_SS.UTF-8
ar_SY.UTF-8
ar_TN.UTF-8
ar_YE.UTF-8
as_IN.UTF-8
ast_ES.UTF-8
ayc_PE.UTF-8
az_AZ.UTF-8
az_IR.UTF-8
be_BY.UTF-8
be_BY.UTF-8@latin
bem_ZM.UTF-8
ber_DZ.UTF-8
ber_MA.UTF-8
bg_BG.UTF-8
bhb_IN.UTF-8
bho_IN.UTF-8
bho_NP.UTF-8
bi_VU.UTF-8
bn_BD.UTF-8
bn_IN.UTF-8
bo_CN.UTF-8
bo_IN.UTF-8
br_FR.UTF-8
brx_IN.UTF-8
bs_BA.UTF-8
byn_ER.UTF-8
ca_AD.UTF-8
ca_ES.UTF-8
ca_ES.UTF-8@valencia
ca_FR.UTF-8
ca_IT.UTF-8
ce_RU.UTF-8
chr_US.UTF-8
ckb_IQ.UTF-8
cmn_TW.UTF-8
crh_RU.UTF-8
crh_UA.UTF-8
cs_CZ.UTF-8
csb_PL.UTF-8
cv_RU.UTF-8
cy_GB.UTF-8
da_DK.UTF-8
de_AT.UTF-8
de_BE.UTF-8
de_CH.UTF-8
de_DE.UTF-8
de_IT.UTF-8
de_LI.UTF-8
de_LU.UTF-8
doi_IN.UTF-8
dsb_DE.UTF-8
dv_MV.UTF-8
dz_BT.UTF-8
el_CY.UTF-8
el_GR.UTF-8
en_AG.UTF-8
en_AU.UTF-8
en_BW.UTF-8
en_CA.UTF-8
en_DK.UTF-8
en_GB.UTF-8
en_HK.UTF-8
en_IE.UTF-8
en_IL.UTF-8
en_IN.UTF-8
en_NG.UTF-8
en_NZ.UTF-8
en_PH.UTF-8
en_SC.UTF-8
en_SG.UTF-8
en_US.UTF-8
en_ZA.UTF-8
en_ZM.UTF-8
en_ZW.UTF-8
eo.UTF-8
es_AR.UTF-8
es_BO.UTF-8
es_CL.UTF-8
es_CO.UTF-8
es_CR.UTF-8
es_CU.UTF-8
es_DO.UTF-8
es_EC.UTF-8
es_ES.UTF-8
es_GT.UTF-8
es_HN.UTF-8
es_MX.UTF-8
es_NI.UTF-8
es_PA.UTF-8
es_PE.UTF-8
es_PR.UTF-8
es_PY.UTF-8
es_SV.UTF-8
es_US.UTF-8
es_UY.UTF-8
es_VE.UTF-8
et_EE.UTF-8
eu_ES.UTF-8
fa_IR.UTF-8
ff_SN.UTF-8
fi_FI.UTF-8
fil_PH.UTF-8
fo_FO.UTF-8
fr_BE.UTF-8
fr_CA.UTF-8
fr_CH.UTF-8
fr_FR.UTF-8
fr_LU.UTF-8
fur_IT.UTF-8
fy_DE.UTF-8
fy_NL.UTF-8
ga_IE.UTF-8
gbm_IN.UTF-8
gd_GB.UTF-8
gez_ER.UTF-8
gez_ER.UTF-8@abegede
gez_ET.UTF-8
gez_ET.UTF-8@abegede
gl_ES.UTF-8
gu_IN.UTF-8
gv_GB.UTF-8
ha_NG.UTF-8
hak_TW.UTF-8
he_IL.UTF-8
hi_IN.UTF-8
hif_FJ.UTF-8
hne_IN.UTF-8
hr_HR.UTF-8
hsb_DE.UTF-8
ht_HT.UTF-8
hu_HU.UTF-8
hy_AM.UTF-8
ia_FR.UTF-8
id_ID.UTF-8
ig_NG.UTF-8
ik_CA.UTF-8
is_IS.UTF-8
it_CH.UTF-8
it_IT.UTF-8
iu_CA.UTF-8
ja_JP.UTF-8
ka_GE.UTF-8
kab_DZ.UTF-8
kk_KZ.UTF-8
kl_GL.UTF-8
km_KH.UTF-8
kn_IN.UTF-8
ko_KR.UTF-8
kok_IN.UTF-8
ks_IN.UTF-8
ks_IN.UTF-8@devanagari
ku_TR.UTF-8
kv_RU.UTF-8
kw_GB.UTF-8
ky_KG.UTF-8
lb_LU.UTF-8
lg_UG.UTF-8
li_BE.UTF-8
li_NL.UTF-8
lij_IT.UTF-8
ln_CD.UTF-8
lo_LA.UTF-8
lt_LT.UTF-8
ltg_LV.UTF-8
lv_LV.UTF-8
lzh_TW.UTF-8
mag_IN.UTF-8
mai_IN.UTF-8
mai_NP.UTF-8
mdf_RU.UTF-8
mfe_MU.UTF-8
mg_MG.UTF-8
mhr_RU.UTF-8
mi_NZ.UTF-8
miq_NI.UTF-8
mjw_IN.UTF-8
mk_MK.UTF-8
ml_IN.UTF-8
mn_MN.UTF-8
mni_IN.UTF-8
mnw_MM.UTF-8
mr_IN.UTF-8
ms_MY.UTF-8
mt_MT.UTF-8
my_MM.UTF-8
nan_TW.UTF-8
nan_TW.UTF-8@latin
nb_NO.UTF-8
nds_DE.UTF-8
nds_NL.UTF-8
ne_NP.UTF-8
nhn_MX.UTF-8
niu_NU.UTF-8
niu_NZ.UTF-8
nl_AW.UTF-8
nl_BE.UTF-8
nl_NL.UTF-8
nn_NO.UTF-8
nr_ZA.UTF-8
nso_ZA.UTF-8
oc_FR.UTF-8
om_ET.UTF-8
om_KE.UTF-8
or_IN.UTF-8
os_RU.UTF-8
pa_IN.UTF-8
pa_PK.UTF-8
pap_AW.UTF-8
pap_CW.UTF-8
pl_PL.UTF-8
ps_AF.UTF-8
pt_BR.UTF-8
pt_PT.UTF-8
quz_PE.UTF-8
raj_IN.UTF-8
rif_MA.UTF-8
ro_RO.UTF-8
ru_RU.UTF-8
ru_UA.UTF-8
rw_RW.UTF-8
sa_IN.UTF-8
sah_RU.UTF-8
sat_IN.UTF-8
sc_IT.UTF-8
scn_IT.UTF-8
sd_IN.UTF-8
sd_IN.UTF-8@devanagari
se_NO.UTF-8
sgs_LT.UTF-8
shn_MM.UTF-8
shs_CA.UTF-8
si_LK.UTF-8
sid_ET.UTF-8
sk_SK.UTF-8
sl_SI.UTF-8
sm_WS.UTF-8
so_DJ.UTF-8
so_ET.UTF-8
so_KE.UTF-8
so_SO.UTF-8
sq_AL.UTF-8
sq_MK.UTF-8
sr_ME.UTF-8
sr_RS.UTF-8
sr_RS.UTF-8@latin
ss_ZA.UTF-8
ssy_ER.UTF-8
st_ZA.UTF-8
su_ID.UTF-8
sv_FI.UTF-8
sv_SE.UTF-8
sw_KE.UTF-8
tt_RU.UTF-8@iqtelif
ug_CN.UTF-8
uk_UA.UTF-8
unm_US.UTF-8
ur_IN.UTF-8
ur_PK.UTF-8
uz_UZ.UTF-8
uz_UZ.UTF-8@cyrillic
ve_ZA.UTF-8
vi_VN.UTF-8
wa_BE.UTF-8
wae_CH.UTF-8
wal_ET.UTF-8
wo_SN.UTF-8
xh_ZA.UTF-8
yi_US.UTF-8
yo_NG.UTF-8
yue_HK.UTF-8
yuw_PG.UTF-8
zgh_MA.UTF-8
zh_CN.UTF-8
zh_HK.UTF-8
zh_SG.UTF-8
zh_TW.UTF-8
zu_ZA.UTF-8
The output of the other command that you posted is as follows:
davidct@fedora:~$ localectl list-locales | grep ca_ES
ca_ES.UTF-8
ca_ES.UTF-8@valencia
I don’t know about the session type, I just use the default. However, after a quick search online I found this command that shows “wayland” as the output:
davidct@fedora:~$ echo $XDG_SESSION_TYPE
wayland
Hmmm, the Catalan locales exist, that part seems to be set up correctly.
I found a really old Ubuntu issue (and a related Freedesktop one) which seems very similar to your problem. From the description in the Ubuntu issue, it seems that this is related to the different Catalan locales and the value of LANG.
On a hunch, I tried to recreate the conditions of the Ubuntu bug report: I set a Catalan keyboard layout in KDE (there is only one) and then I ran Dolphin, with LANG set to ca_ES.UTF-8@valencia and ca_ES.UTF-8:
~ ❯ LANG=ca_ES.UTF-8@valencia dolphin
# [qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile]
# this is an unrelated error about the color profile on my laptop
xkbcommon: ERROR: couldn't find a Compose file for locale "ca_ES.UTF-8@valencia" (mapped to "ca_ES.UTF-8@valencia")
qt.qpa.input.methods: failed to create compose table
~ ❯
~ ❯ LANG=ca_ES.UTF-8 dolphin
# [qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile]
# this is an unrelated error about the color profile on my laptop
~ ❯
Note the errors when LANG=ca_ES.UTF-8@valencia. And sure enough, in this instance of Dolphin, when I type the key to the right of P (which is my testcase as it is the only one I am relatively sure should be a dead key in the Catalan layout), followed by an e, I get a regular e in Dolphin’s address bar. In the second instance, with LANG=ca_ES.UTF-8, I get è in the address bar.
Could you please start one of your problem application with LANG=ca_ES.UTF-8 set and check if this fixes it?
Thanks for the thorough investigation. Could you please let me know how to start an application with a different locale?
You can pass arbitrary environment variables to a command when running it from a shell, including overriding existing ones, by listing the NAME=value pairs before the actual command:
The ~ ❯ in these code blocks is my actual shell prompt (well, the second line of my prompt anyway).
Almost since the beginning of my Linux KDE adventure I am using the Eurkey Keyboard layout. I wrote about this several times in forums of the distro’s I was using at the time. For me this works perfectly, I seldom got any positive comment on my remarks about this layout. Either people don’t want to use it, or it doesn’t work for them, although I would have expected some negative comment.
You can choose the layout in the KDE settings:
After having it added you can see a preview of the layout by clicking the button with the 3 dots on the far right of the picture above. Now you can see which buttons to press when you want a certain character.
You always have to use the right-CTRL key (alt gr on my keyboard) in combination with another key to get this:
(a) ä Ä, (e) ë Ë, (c) ç Ç, (s)ß, (n) ñ Ñ
Yes, some learning is required but the layout is obvious enough to reduce that to a minimum. I don’t use ZapZap and don’t know why it reacts differently to the normal way of getting special characters in other programs. Maybe it works with Eurkey layout, maybe not. It’s always possible to delete the layout from the settings if it doesn’t.
From the tests with LANG set to two different ca_ES variants on my machine, the resulting xkbcommon error, and looking at /usr/share/X11/locale/compose.dir, I am now fairly certain this is caused by the LANG=ca_ES.UTF-8@valencia setting on the OP’s system and the fact that this is not listed in /usr/share/X11/locale/compose.dir. Let’s wait for @davidct to confirm that behavior before throwing other ideas into the ring.
Oh, @davidct, while you are testing it, can you please also start Dolphin from the shell without passing another value for LANG and post the output here (please note: when you do, make sure that you type a dead key in the application, the xkb error only shows up on the console once xkb sees a dead key and has a reason to compose a character):
~ ❯ dolphin
This will show us any errors with your system-wide locale settings and I expect that you will see the same xkbcommon error on your system as I did when I explicitly set LANG=ca_ES.UTF-8@valencia.
Lars, switching my system language to ca_ES solves the problem. And indeed, when I start dolphin with ca_ES.UTF-8@valencia I get the xkb error (plus other errors).
davidct@fedora:~$ LANG=ca_ES.UTF-8@valencia dolphin
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
kf.kio.core.connection: Socket not connected QLocalSocket::PeerClosedError
kf.kio.core: An error occurred during write. The worker terminates now.
QThreadStorage: Thread 0x5646ace32c00 exited after QThreadStorage 8 destroyed
QThreadStorage: Thread 0x5646ace32c00 exited after QThreadStorage 2 destroyed
QThreadStorage: Thread 0x5646ace32c00 exited after QThreadStorage 1 destroyed
xkbcommon: ERROR: couldn't find a Compose file for locale "ca_ES.UTF-8@valencia" (mapped to "ca_ES.UTF-8@valencia")
qt.qpa.input.methods: failed to create compose table
QThreadStorage: Thread 0x562d737a2780 exited after QThreadStorage 9 destroyed
If I use ca_ES, the xkb error does not appear, and the accent dead keys work fine:
davidct@fedora:~$ davidct@fedora:~$ LANG=ca_ES.UTF-8 dolphin
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
org.kde.dolphin: Could not load default global viewproperties
kf.kio.core.connection: Socket not connected QLocalSocket::PeerClosedError
kf.kio.core: An error occurred during write. The worker terminates now.
QThreadStorage: Thread 0x55602ad33c00 exited after QThreadStorage 8 destroyed
QThreadStorage: Thread 0x55602ad33c00 exited after QThreadStorage 2 destroyed
QThreadStorage: Thread 0x55602ad33c00 exited after QThreadStorage 1 destroyed
QThreadStorage: Thread 0x55fa83b9d780 exited after QThreadStorage 9 destroyed
Can this be fixed in the repository?