| Summary: | konqueror eats XIM Control-Key as Short-cut | ||
|---|---|---|---|
| Product: | unknown | Reporter: | Takumi ASAKI <takumi> |
| Component: | general | Assignee: | Ellis Whitehead <ellis> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Unlisted Binaries | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Takumi ASAKI
2002-11-15 11:02:56 UTC
What is XIM? Is it an application you're running from an embedded konsole? If so, this problem should already be fixed, since konsole overrides all Ctrl+<key> shortcuts now. Or is it a konqueror part? If so, whoever's responsible for it can check out the konsole part to see how this is done. In eventFilter(), AccelOverride events need to be processed for the desired keys. In any case, it doesn't have anything to do with kdelibs. XIM is X Input Method. Please see http://www.suse.de/~mfabian/suse-cjk/xim.html We needs XIM to input non-ascii charcters. ex. Japanese, Chinese, Korean. KDE and Qt supports XIM. To input Japanese, we use `conversionStartKey' and enter XIM-input mode. In XIM-input mode, All of key-code should be passed to XIM server first. But current(3.1rc3)'s konqueror eat shortcut-key first. So we can't control XIM. KDE-3.0 doesn't have this bug. Kate had same bug. And fixed it. http://bugs.kde.org/show_bug.cgi?id=50386 http://lists.kde.org/?l=kde-cvs&m=103747068313209&w=2 http://lists.kde.org/?l=kde-cvs&m=103747104813405&w=2 It's Qt's bug. After Qt-3.1.1 It's fixed. |