Bug 103788 - Input of arbitrary unicode characters as defined in ISO 14755
Summary: Input of arbitrary unicode characters as defined in ISO 14755
Status: RESOLVED INTENTIONAL
Alias: None
Product: kwin
Classification: Plasma
Component: input (show other bugs)
Version: unspecified
Platform: Mandrake RPMs Linux
: HI wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: wayland
: 187263 231823 410233 421127 443543 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-04-13 13:31 UTC by Helge Hielscher
Modified: 2024-10-03 21:08 UTC (History)
20 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Helge Hielscher 2005-04-13 13:31:03 UTC
Version:            (using KDE KDE 3.3.2)
Installed from:    Mandrake RPMs

please support the input of arbitrary unicode characters as defined in ISO 14755
http://www.cl.cam.ac.uk/~mgk25/volatile/ISO-14755.pdf
Comment 1 Thiago Macieira 2005-04-13 23:58:42 UTC
I think this is more of a Qt issue.
Comment 2 Nicolas Goutte 2005-09-10 16:03:16 UTC
You probably should report the wish to qt-bugs (at) trolltech.com

Have a nice day!
Comment 3 Helge Hielscher 2007-02-20 10:54:35 UTC
reported upstream:
Task 150387 - It would be useful to have full support of unicode characters as defined in ISO 14755.
http://www.trolltech.com/developer/task-tracker/index_html?id=150387&method=entry
Comment 4 Daniel Aleksandersen 2007-07-22 08:46:05 UTC
*** This bug has been confirmed by popular vote. ***
Comment 5 Daniel Aleksandersen 2007-07-22 08:47:16 UTC
GTK+2—and even Windows XP—supports this.
Comment 6 Helge Hielscher 2008-07-15 12:33:52 UTC
upstream:
Task 71224 - Qt/X11 does not allow input of Unicode characters using Ctrl+Shift followed by the character code
http://trolltech.com/developer/task-tracker/index_html?id=71224&method=entry
Comment 7 Dotan Cohen 2009-10-13 13:26:40 UTC
*** Bug 187263 has been marked as a duplicate of this bug. ***
Comment 8 Christoph Feck 2009-12-09 22:53:52 UTC
http://bugreports.qt.nokia.com/browse/QTBUG-8
Comment 9 Dotan Cohen 2010-02-23 21:37:37 UTC
The Qt devs conclude this:
"This seems like a feature that should belong in the window-system and/or input-method, not in each toolkit."

Therefore, Qt won't "fix" it and are passing he ball back to KDE.
Comment 10 Andreas Pakulat 2010-02-23 22:31:03 UTC
No they didn't, they actually moved it further upstream, i.e. X11 or the input-method you're using (scim or uim for example).
Comment 11 Dotan Cohen 2010-02-24 00:01:56 UTC
Where do you see that, Andreas? Here is the Qt bug:
http://bugreports.qt.nokia.com/browse/QTBUG-8

I see no mention of X11 or scim/uim. The bug was resolved CLOSED as a feature request because the bug assignee does not think that it is a Qt issue.

If this really was pushed further upstream, please link to the upstream bugs. Thanks.
Comment 12 Andreas Pakulat 2010-02-24 08:51:24 UTC
(In reply to comment #11)
> Where do you see that, Andreas? Here is the Qt bug:
> http://bugreports.qt.nokia.com/browse/QTBUG-8
> 
> I see no mention of X11 or scim/uim.

"windows-system" is clearly X11 for linux, note this is not the same as 'window-manager'. In particular the window-manager has nothing to do with typing any kind of text. Additionally the assignee mentioned "input-method" which scim/uim are.

> The bug was resolved CLOSED as a feature
> request because the bug assignee does not think that it is a Qt issue.

Right, the assignee thinks it should be done in the input-method or the window-system and not the Qt toolkit. Both are further "up" on the stack, while KDE is down on the software stack (compared to Qt).

> If this really was pushed further upstream, please link to the upstream bugs.

Unfortunately I can't as the assignee didn't mention any bugreport he opened, apparently their policy on how to handle such things is differently than KDE's. Hence somebody who wants this feature will have to go to x.org and file a new request with them.
Comment 13 Dotan Cohen 2010-02-25 09:29:05 UTC
Thank you Andreas. Here is the Xorg bug:
https://bugs.freedesktop.org/show_bug.cgi?id=26747

Please comment there and correct my report if there are any errors. I am not a developer, but of course I want the report to be accurate.
Comment 14 Christoph Feck 2010-03-23 12:57:01 UTC
*** Bug 231823 has been marked as a duplicate of this bug. ***
Comment 15 Arran 2015-02-17 08:37:28 UTC Comment hidden (spam)
Comment 16 Navid Zamani 2015-02-17 12:58:07 UTC Comment hidden (spam)
Comment 17 Arran 2015-04-01 16:30:49 UTC Comment hidden (spam)
Comment 18 Christoph Feck 2019-07-26 14:35:30 UTC
*** Bug 410233 has been marked as a duplicate of this bug. ***
Comment 19 Thomas Friedrichsmeier 2020-04-01 16:16:54 UTC
For what it's worth, looking for a solution to this problem myself, I found that ibus provides this under the label "Emjoi choice", the default shortcut being Ctrl+Shift+E. Despite it's name it still allows numerical input of any unicode code point, and seems to work well across apps of different toolkits.

Frankly, I'm a bit uncertain about how ibus relates to KDE's "Keyboard Hardware and Layout" settings (I fear it's probably two completely separate solutions for essentially the same problem), but I hope my comment will point users to a workaround, and developers to a potential mid term approach to a proper solution.
Comment 20 Christoph Feck 2020-05-06 23:31:49 UTC
*** Bug 421127 has been marked as a duplicate of this bug. ***
Comment 21 Claudius Ellsel 2020-10-03 15:17:06 UTC
I had a short look.

Unfortunately most links to upsteam bug trackers are outdated.

One for X11 is at https://gitlab.freedesktop.org/xorg/lib/libx11/-/issues/9.

However that would probably not work on Wayland?

Does somebody here have more knowledge about this? Also whether this is still considered to be an upstream issue (probably of Qt)?
Comment 22 Christoph Feck 2020-11-01 13:58:20 UTC
> probably of Qt

This isn't the responsibility of the UI toolkit. Whatever in the system converts raw key codes to Unicode characters is responsible. On Wayland, this may indeed be the compositor (kwin_wayland), but I don't know the details of the Wayland input stack.
Comment 23 Claudius Ellsel 2020-11-01 14:35:23 UTC Comment hidden (spam)
Comment 24 Roke Julian Lockhart Beedell 2023-07-09 19:41:39 UTC Comment hidden (spam)
Comment 25 Jan Rathmann 2023-11-01 09:46:13 UTC
*** Bug 443543 has been marked as a duplicate of this bug. ***
Comment 26 Jan Rathmann 2023-11-01 09:55:08 UTC
Reopening.
Verified that entering unicode chars (in Kate) still doesn't work currently on Kubunu 23.10 (Plasma 5.27.8) and Neon Unstable (Plasma 6).

If it is not on Qt's side to implement this (as Christoph tells in #22), which component would be correct to assign this bug?
Comment 27 Roke Julian Lockhart Beedell 2023-11-01 15:47:27 UTC
(In reply to Helge Hielscher from comment #3)
> reported upstream:
> Task 150387 - It would be useful to have full support of unicode characters
> as defined in ISO 14755.
> http://www.trolltech.com/developer/task-tracker/
> index_html?id=150387&method=entry

What would be the new link to that? I've been unable to locate it – I worry that upstream has somehow accidentally nuked it from their tracker, and thus that we're perhaps missing input there.
Comment 28 Nate Graham 2023-11-01 17:51:25 UTC
Can someone explain in plain English what exactly is being requested here? I'm not understanding what needs to be done to support it, because it isn't clear to me what the feature is. Thanks!
Comment 29 Jan Rathmann 2023-11-01 21:45:38 UTC
(In reply to Nate Graham from comment #28)
> Can someone explain in plain English what exactly is being requested here?
> I'm not understanding what needs to be done to support it, because it isn't
> clear to me what the feature is. Thanks!

The feature is to be able to insert arbitrary unicode characters in text fields (or a text editor) by pressing Ctrl+Shift+u and then the hexadecimal number of the unicode character.
Example: Ctrl+Shift+u + 1F600 will give you the emoji 😀.
You can test it in Firefox or other GTK-based applications.
More details on https://en.wikipedia.org/wiki/Unicode_input (Note: The article claims that it is supported by Qt applications on Linux, what doesn't seem to be correct)
Comment 30 Jan Rathmann 2023-11-03 13:55:53 UTC
Here's a Qt bug report, but it's only for X11:
https://bugreports.qt.io/browse/QTBUG-8
(It doesn't work on Wayland either. Haven't found a report for Wayland in the Qt bug tracker.)
Comment 31 Lukas Kucharczyk 2024-06-30 10:56:45 UTC
(In reply to Nate Graham from comment #28)
> Can someone explain in plain English what exactly is being requested here?
> I'm not understanding what needs to be done to support it, because it isn't
> clear to me what the feature is. Thanks!

Typing arbitrary Unicode characters by their codepoint using a keyboard shortcut. You can even try exactly what people mean if you're running any GTK app in Plasma. For example https://unicode-explorer.com/c/237D can be typed by holding Ctrl+Shift+u and then typing 237d, then letting go.

By the way, KRunner's Special Characters plugin can already do the conversion but copying characters from KRunner every time you want to do this is not ideal.
Comment 32 Nate Graham 2024-07-23 18:20:11 UTC
I'm a bit confused by the Qt folks' decision that this should be done by compositors. To me the toolkit itself seems like the right place to do it. Notably that decision was taken 14 years ago, so I wonder if it could be reconsidered.

Implementing it in the compositor or as an input method doesn't make much sense to me since then it would conflict with the behavior in GTK, which would have to be somehow globally disabled when our version of it was running.
Comment 33 David Edmundson 2024-09-27 08:05:44 UTC
We're not doing this in kwin.
Comment 34 Nate Graham 2024-10-03 21:08:17 UTC
Qt says they're not the right layer, you say KWin isn't the right layer… what is the right layer? Doing it as an input method? If so, we should re-open this and consider it part of the Input goal.