Hi,
Not sure if this is related to Wayland but sometimes I need to write special characters. On Windows I would go CTRL+’ASCII CODE’ but on Linux / Fedora it seems to be CTRL+SHIFT+U which works in web applications however I noticed that in some applications like KWRITE that does not work at all. Any one else have this issue?
Thanks
In KDE by default, the Ctrl+Shift+U method works in GTK apps but not native KDE (i.e. Qt) apps.
You can make it work in Qt apps by enabling “iBus Wayland” as a virtual keyboard. However, personally I found that enabling the iBus Wayland VK gave unwanted side effects, so I ended up using compose sequences for my needs.
±.See also:
Hey PG, thanks for the help. I saw that compose key method through bindings but that would cause other side effects for keys that some applications I use need..
So I guess comes down to a Wayland + KDE issue?
Fair enough. You could always try enabling iBus Wayland as a virtual keyboard and see how that works for you.
I had some issues with that as I said, but it was ~8 months ago and there have been plenty of Plasma enhancements since then, so it might work better for you now.
IF you don’t mind me asking, how do I go about enable ibus wayland?
Sure. In the System Settings, go to Keyboard >> Virtual Keyboard. You should see three icons (“None”, “iBus Wayland” and “Maliit”).
Select iBus Wayland, click “Apply”, and then you can try Ctrl+Shift+U codes in Qt apps.
I do not understand how that would break things unless you stopped the Alt Gr key from working as the compose key.
For example, if I decide to use LEFT CTRL as the compose key, if you then open any editor and do LEFT CTRL + A for select all text, that will no longer work. So whatever key you use, if in that case you use ALT GR (assuming you mean RALT) then if that key was used somewhere else for something else it no longer works.. I was more hoping that a compose key would not “remove” whatever functionality that key had before like in my case LCTRL and I used LCTRL specifically because under Windows I could LCTRL+XXX (where XXX is a ascii number) and it would print it.
I hope that clears a few things. I guess that for the time being, I’ll just use KCHARSELECT when CTRL+SHIFT+U doesn’t work for an application (like KWRITE) and just used CTRL+SHIFT+U where it does until the Wayland+KDE issue is fixed.
Outside of video games it is very rare that left vs. right of ctrl/alt/shift matters.
Therefore using the default of right-alt (which is engraved Alt Gr on all my keyboards)
does not create an issue, just use the left-alt for Alt keys.
Do you have apps that bind left and right shift/ctrl/alt for there own use?
Yes I do so that is unfortunately not an option for me. It is a cool feature (compose key) but that CTRL+ASCII CODE support should be available in Fedora.
Hi Patrick,
I have suggested this several times here on the forum but get the idea nobody wants to use my idea.
Are your special keys in the following picture:
Altgr + a = ä, Altgr + Shift + a = ÄHi JandeMus,
Certainly is a nice idea and a worthy alternative for sure. However, what I’m hoping is that they wont drop the ball on this just because there are ways around. I have just gotten used to this on Windows where LCTRL+ASCII code just gives me what I want. I was told this worked before and I hope it will be fixed in the future.
I’m actually not sure it did work before? Certainly this ticket is older than Wayland:
I wonder is this just something happening with KDE Plasma or does it work in gnome LCTRL+ASCII CODE ??
Ctrl+Shift+U followed by the Unicode point works in GNOME[1]. Historically that worked through GTK doing the translation from the input key sequence to the Unicode character.
Qt refuses to do that, so (as discussed in the bug ticket), to make it work in Plasma on Qt apps, the conversion needs to sit at a different point in the stack. So it’s been implemented in the “iBus Wayland” input method, though from my experience that still needs some polishing.
From what I can see, GNOME may now also use iBus for this rather than relying on GTK, but I’m not 100% sure on that.
Not sure that LCtrl + code works anywhere. Windows uses Left Alt + code, from what I remember (Alt 0150 for en dash is still burned into my muscle memory).
at least in anything GTK based, like all the core GNOME apps. Not sure what happens if you run a Qt app in GNOME ↩︎
Pedantically its not ASCII code you are entering.
After all on a QWERTY keyboard all the 96 printing ASCII characters can just be typed.
On Windows it was the OEM code page code.
But what you would want these days is a unicode code point,
of which there are 1.2 ish million defined so far.
That seems stubborn of them to refuse to do that. I love KDE but who knows I may jump to Gnome eventually.. Or maybe COSMIC DE. I’ll have to try it in a VM before I commit, Cosmic DE is still very new but I have been impressed by how fast they release fixes and features.
That key combination, defaults to changing the case of a letter to lowercase in kwrite. Which is does for me in Fed 43.
Which is also the same key combination suggested to ouput ascii characters; you can try it on any web application.. For instance printing “®” is achieved by pressing CTRL+SHIFT+U then entire 00ae and pressing the space bar and it will print. Since CTRL+SHIFT+U is assigned to do something else in Kwrite that explains why it isn’t working.
I tried to remove the default lower case in KWRITE but that doesn’t solve the issue anyway.
In google mail I can get thinks like 뮻B but after a few updates kwrite appears to have stopped responding to ctrl+shift+u
