| Summary: | Input of arbitrary unicode characters as defined in ISO 14755 | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Helge Hielscher <hhielscher> |
| Component: | input | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | wishlist | CC: | 16303, 4wy78uwh, bruno13, claudius.ellsel, curan, ekotekbiz74, herzenschein, jan.rathmann, julian, kde-2011.08, kde, ks.hot.ua, lukas, nate, navid.zamani, nicolasg, rnddim, samjnaa, santiago777, thomas.friedrichsmeier |
| Priority: | HI | Keywords: | wayland |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Mandrake RPMs | ||
| OS: | Linux | ||
| See Also: | https://bugreports.qt.io/browse/QTBUG-8 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Helge Hielscher
2005-04-13 13:31:03 UTC
I think this is more of a Qt issue. You probably should report the wish to qt-bugs (at) trolltech.com Have a nice day! 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 *** This bug has been confirmed by popular vote. *** GTK+2—and even Windows XP—supports this. 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 *** Bug 187263 has been marked as a duplicate of this bug. *** 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. 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). 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. (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. 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. *** Bug 231823 has been marked as a duplicate of this bug. *** I can not accept these responses. It works with Ubuntu. So it can well be done in KDE too. This shoving around a very important convenience from one to each other is really one of the reasons that Linux has real problems to become really popular. That it is considered as important can be seen in Comment 4: « *** This bug has been confirmed by popular vote. *** » I do indeed hope, it can be attributed to somebody who is ready to try to solve it. Well, the thing is: This is not some company that we paid for, neither do they necessarily want to. But instead, the source is open and free from the Content Mafia, and everybody can change things himself, or hire somebody or whatever. It’s another way of thinking that people who still think in the Microsoft/Apple box (like pretty much all Ubuntu and iDevice people, and far too many from Mozilla and the Plasma team) don’t seem to (want to[?]) get. It’s not *that* expensive to hire some developers. :) Many companies do it. Which is how most important open-source projects survive currently AFAIK. If we have a genuine need (spoiler: we do), and there’s enough people (seems like it), we could start a micro-Kickstarter or bounty on some other site, share the costs, and tell our favourite developers about it. :) I, personally, have given up on KDE, and “desktop” environments, applications, widget sets, window managers, etc in general, have seen the iDevicelikes and WhatWG cancers, and moved in a quite different direction, developing a very different user environment, primarily for me (and happily me alone), as I write this. So I’m out. But if you want, go ahead and set a bounty. :) (I wish bug trackers generally offered a bounty feature. :) How would I do that? How expensive would that be? Any thoughts? Are we speaking in hunderds, thousends or more? *** Bug 410233 has been marked as a duplicate of this bug. *** 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. *** Bug 421127 has been marked as a duplicate of this bug. *** 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)? > 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.
Hm, that means this bug should be reopened? (In reply to Claudius Ellsel from comment #23) > Hm, that means this bug should be reopened? Seems like it based upon that comment. *** Bug 443543 has been marked as a duplicate of this bug. *** 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? (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. 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! (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) 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.) (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. 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. We're not doing this in kwin. 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. |