Can't Type Characters With Accents But It's Hit-Or-Miss

I’m sorry, I know the title isn’t as specific as anyone would really care for, but this is a very odd problem and I don’t know how to concisely encapsulate it for a title.

I typically use the US English/Macintosh layout because there’s assorted characters and sometimes (though not always) accented letters I like to be able to type. Anyhow, what I’ve noticed is there are some places that I cannot get it to work but only partially. So, for example, if I’m naming a file, or if I’m in the Gnome text editor, or in the terminal (Console) and probably other places as well, some AltGr-summoned characters will work (for example, I can type the ß character) but a lot of others won’t type. However, if I’m in other programs such as Firefox, or xed, or Scribus, or GIMP, or etc. etc., all the characters that wouldn’t type, do.

Now, I think that there may be a misassignment here of the keyboard layout, but I cannot for the life of me really narrow down the root cause, because everywhere I know to look, I can’t find anything amiss.

What is that ?

Let’s try and narrow this down a little bit –

  1. Apple keyboard → meaning that you’re using Apple Mac hardware – presumably with an Intel CPU …
    Is there any reason to doubt this assumption?
    BTW, I also have a MacBook Air with M3 CPU and German Apple keyboard - it has „ß”, „Ü”, „Ö” and „Ä” keys but, alas no „~” on a key, which is a bit of a pain → macOS (BSD UNIX®) <option+N> :imp:
  2. GNOME → Gtk → <Using XCompose to type special characters>
  3. Scribus is a Qt application –
 > LANG=C zypper info --requires scribus
Loading repository data...
Reading installed packages...


Information for package scribus:
--------------------------------
Repository     : repo-oss
Name           : scribus
Version        : 1.6.5-3.2
Arch           : x86_64
Vendor         : openSUSE
Installed Size : 83.8 MiB
Installed      : Yes
Status         : up-to-date
Source package : scribus-1.6.5-3.2.src
Upstream URL   : https://www.scribus.net/
Summary        : Page Layout and Desktop Publishing (DTP)
Description    : 
    Scribus is a page layout program which produces output in PDF and
    Postscript.

    Scribus supports publishing features such as CMYK and spot colors,
    PDF creation, Encapsulated Postscript import and export and creation
    of color separations.
Requires       : [69]
 . 
 . 
    libQt5Core.so.5()(64bit)
    libQt5Core.so.5(Qt_5.15)(64bit)
    libQt5Core.so.5(Qt_5)(64bit)
 . 
    libQt5Gui.so.5()(64bit)
    libQt5Gui.so.5(Qt_5)(64bit)
 . 
    libQt5Widgets.so.5()(64bit)
    libQt5Widgets.so.5(Qt_5)(64bit)
 . 
    libQt5Network.so.5()(64bit)
    libQt5Network.so.5(Qt_5)(64bit)
 . 
    libQt5Xml.so.5()(64bit)
    libQt5Xml.so.5(Qt_5)(64bit)
    libQt5PrintSupport.so.5()(64bit)
    libQt5PrintSupport.so.5(Qt_5)(64bit)
 . 
 . 
 >
  1. The rest are GTK applications …

Basically, AFAIKS, applications running on the GNOME Desktop, regardless of being GTK or Qt based or not, special characters can be inserted without any issues at all.
However, the GNOME Desktop applications are possibly misbehaving due to the need to explicitly define key sequences to handle Ü, ü, Ä, ä Ö, ö, ß, §, °, ^, and ~ and € …

That would be a keyboard layout.

I’m not sure exactly how you come to the conclusion for Point #1, especially given what I wrote initially:

I typically use the US English/Macintosh layout because there’s assorted characters and sometimes (though not always) accented letters I like to be able type.

I did some further digging, and my suspicion proved to be correct:

Now, I think that there may be a misassignment here of the keyboard layout, but I cannot for the life of me really narrow down the root cause, because everywhere I know to look, I can’t find anything amiss.

Even though in Settings > Keyboard > Input Sources it lists English (Macintosh, ABC, ANSI), when I check things out with localectl status, I get the following:

System Locale: LANG=en_US.UTF-8
    VC Keymap: us
   X11 Layout: us
    X11 Model: pc105+inet
  X11 Options: terminate:ctrl_alt_bksp

For comparison, I have a Fedora 43 KDE VM set up, totally stock except that I picked the same keyboard layout during setup that I did on the host system, and look at what I get there:

System Locale: LANG=en_US.UTF-8
    VC Keymap: us-mac
   X11 Layout: us
    X11 Model: pc105
  X11 Variant: mac

And that suggests to me that for some reason the entire system isn’t respecting the keyboard layout choice. The terminal doesn’t, the file manager doesn’t, but as I mentioned above, other programs, seemingly at random, do (or, conversely, don’t) and I’m not really sure why or what to do about it.

I haven’t set up an equivalent Tumbleweed/KDE VM, though I guess I could.

@Babylon5Nut:

Please check the content of the following files –

  • /etc/locale.conf
  • /etc/vconsole.conf

And also the content of the user’s system variable “LANG” –

> echo $LANG


OK, I can now believe that, you’re using GNOME: <Use alternative keyboard layouts> –

  • And, the GNOME help suggests that, you can check what’s actually available by typing the following in a Terminal window:

> gsettings set org.gnome.desktop.input-sources show-all-sources true


When you initially installed the systems, which choices did you make during the installation procedure for the Keyboard layout?

Ok, so, going in order:

/etc/locale.conf:
LANG=en_US.UTF-8

/etc/vconsole.conf:

# Written by systemd-localed(8) or systemd-firstboot(1), read by systemd-localed
# and systemd-vconsole-setup(8). Use localectl(1) to update this file.
KEYMAP=us
FONT=eurlatgr.psfu
FONT_MAP=
FONT_UNIMAP=
XKBLAYOUT=us
XKBMODEL=pc105+inet
XKBOPTIONS=terminate:ctrl_alt_bksp

echo $LANG:
en_US.UTF-8

gsettings set org.gnome.desktop.input-sources show-all-sources true:
[nothing came up, just went back to the input prompt]

So, the installer itself isn’t where you get to pick your preferred layout (unlike in other distros), so strictly speaking it was the default layout for an otherwise USA English-localized installation. More-or-less immediately after installation, I then went into Settings > Keyboard > Input Sources and found and selected English (Macintosh, ABC, ANSI).

Now, last night after reading and responding in this thread, I conducted an experiment and created a new VM with Tumbleweed but the KDE desktop. I set it up identically to how the host system is, and it shows the same output from localectl status that my host system does, but it works as I would expect. That is, not like the host system works. If I want to type, oh, I dunno, “über” for example, I can type it anywhere, perfectly.

What happens if you run the command localectl set-keymap us-mac and then restart your user session?

Basically nothing, no change, except that localectl status now returns:

System Locale: LANG=en_US.UTF-8
    VC Keymap: us-mac
   X11 Layout: us
    X11 Model: microsoftpro
  X11 Variant: mac
  X11 Options: terminate:ctrl_alt_bksp

But I still can or cannot type symbols or accented characters, as before.

Ok, so I decided to see what in total the difference is by typing out all the character possibilities in a program that lets me type everything, and then someplace which doesn’t. I’m not going to type the regular or shift variants because they both work perfectly. It’s just the [AltGr] and [Shift]+[AltGr] combinations:

“Works Correctly”:
AltGr:
` ¡ ™ £ ¢ ∞ § ¶ • ª º – ≠
œ ∑ ´ ® † ¥ ¨ ^ ø π “ ‘ «
å ß ∂ ƒ © ̇ ˚ ¬ … æ
Ω ≈ ç √ ∫ ~ µ ≤ ≥ ÷

Shift + AltGr:
` € ‹ › fi fl ‡ ° · ‚ — ±
Œ „ ´ ˇ ¼ ¨ ˆ Ø ∏ ” ’ »
Å ̵ ð ˀ ˝ ̣ ½  Þ þ Æ
¸ ˛ Ç ◊ ı ˜ ¾ ¯ ˘ ¿

“Doesn’t Work Correctly”:
AltGr:
¡ ™ £ ¢ ∞ § ¶ • ª º – ≠
œ ∑ _ ® † ¥ _ _ ø π “ ‘
å ß ∂ ƒ © _ ∆ _ ¬ … æ
Ω ≈ ç √ ∫ _ µ ≤ ≥ ÷

Shift + AltGr
_ ⁄ € ‹ › fi fl ‡ ° · ‚ — ±
Œ „ ´ ‰ _ ¼ ¨ ˆ Ø ∏ ” ’ »
Å _ ð _ _ _ ½  Þ þ Æ
_ _ Ç ◊ ı ˜ ¾ _ _ ¿

[Note: In the diagram above under the “Doesn’t Work Correctly” section, I used an underscore, “_”, to designate a spot where there ought to be a character, but isn’t.]

But for the most part, where there is a standard Latin character but with some kind of accent mark above it (for example, à or ö or ñ) there’s just nothing.

Alright, I just created a VM with Tumbleweed/Gnome, went through the setup process and it’s now totally stock, other than the system update.

I switched layouts from English (US) to English (Macintosh, ABC, ANSI) and removed the other one, and restarted the system, and it’s behaving identically to my host system. So, that helps narrow whatever the issue is down to being somehow openSUSE & Gnome related.

Right now, I’m setting up a Fedora 43 Gnome VM, and instead of doing what I usually do (that is, pick the keyboard layout during the installation process) I’m going to replicate what you have to do with openSUSE, and leave the default US keyboard, then change it after I reboot to the desktop.

Ok, I just completed the installation and setup, exactly as described above. That is, I let the installer keep the standard English (US) layout, and then once I was logged into the new desktop installation, I changed the input to the Fedora equivalent (the naming conventions are slightly different) of English (Macintosh), restarted the system, and everything works correctly. Therefore, whatever the issue I’m having has to be openSUSE + Gnome specific, since the problem doesn’t occur in Tumbleweed/KDE, and it doesn’t occur in Fedora/KDE or Fedora/Gnome.

I also created an Ubuntu 25.10/Gnome VM, did exactly the same process on it as described above for Fedora 43/KDE, and it works perfectly, too.

Could you provide a test case? I mean, which keys should be pressed and the expected and obtained results.

Well, I don’t know how much more you need, but ok…

AltGr+u should temporarily give you a floating umlaut, and then when you type a letter that has an umlauted version, you should see that character with the umlaut above it. For example, ü, or ÿ, etc.

What does happen is you get nothing, and then when you type, for example, u or y, you just get a u or a y. Other characters like the esset, which are not an alternate version of some other character, type immediately, which is also what should happen.

To me, this is a bug. I checked here and it seems that the Gnome applications are ignoring dead keys.

Install ibus, reboot and that should solve the problem (zypper install ibus).

There’s more than one way to type “ü”. I understand you’re typing in German; if that’s the case, have you tried the “German (US)” keyboard layout?

Next time, add a picture of your keyboard.

Et voilà!

.

There’s more than one way to type “ü”. I understand you’re typing in German; if that’s the case, have you tried the “German (US)” keyboard layout?

I’m not, actually. Not really sure why folk here keep trying to assume things without any basis and which aren’t factual.

Honestly, I didn’t understand your tone here.

I am dutch and for NL the diacritics are very important too.In f.e. French, Czech ditto. No idea why people always assume that using accented chars are a typical German thing. ( which are not even used in German, i.e. the á, é, è, ô ) . Diacritics have a much wider definition and include f.e. ø, °, ç, š, ä, ß , æ . A French, Dutch or Czech person is not being helped with a German keyboard or a German (US) one.

1 Like

I mentioned at the start of this discussion thread that I use the Macintosh variant of the U.S. keyboard layout for purposes of giving a sufficiently comprehensive view of my system’s configuration. I use that layout because I like it: I’m easily able to access a variety of symbols, and periodically I also have need of characters with accent marks.

I truly do appreciate being put onto the ibus thing, which as I mentioned above solved the problem.

Thank you for the clarification.

By the way, it was just a tip. Not everyone knows about the keyboard layout options.
I’m glad you found what works best for you.