What version of the product are you using? On what operating system? OS (Linux distributions, UNIX or ...): Fedora 21 Alpha Architecture (i386, x86_64): x86_64 IBus version: 1.5.9 Input method name and version: ibus-hangul, 1.4.2 Python version: 2.7.8 dbus version: 1.8.6 dbus-python version: 1.2.0 gtk version (if bug is about gtk applications): qt version (if bug is about qt applications): Qt 5.3 branch tip (reports as 5.3.3)

When I am typing a Hangul block into a Qt 5 app, the input method plugin will construct multiple QInputMethodEvents and send them to the active widget with the correct pre-edit text before the block is complete and committed.

Unfortunately, the attribute list for each pre-commit QInputMethodEvent contains multiple attributes of type TextFormat for the same range. In the Qt 5.3 docs, this is listed as undefined behavior: "If several are specified for any character in the string the behaviour is undefined."

The reason this happens is that the plugin receives a text event from ibus with multiple color text attributes with different types, one for the foreground and one for the background. It then converts both of those into QTextCharFormats and adds them to the attribute list.

This isn't a good idea, both because Qt states the behavior for this is undefined, but also because it's not how QTextCharFormat works: A QTextCharFormat can have both a foreground and a background brush.

What the plugin should do instead is combine both of the ibus attributes into a single QTextCharFormat with foreground and background set.

This behavior currently badly breaks pre-edit text in KDE's Kate text editor: https://bugs.kde.org/show_bug.cgi?id=339467

Kate applies both of the QTextCharFormats to the text, and because the second text attribute has NoBrush as pen() the text is rendered invisible. Note that Kate cannot use QTextFormat::merge() to combine them, because it can't know which is the foreground and which is the background, so the operand order is unclear. It could ignore the second QTextCharFormat, but then it would lose the background color information. That's why this really needs to be fixed in the plugin.

Sorry, I just noticed that you seem to prefer tracking bugs for the plugin at Qt's Jira. I'll file there.

https://bugreports.qt-project.org/browse/QTBUG-41640

Thank you for filing the bug and patch. I may close the bug later.

Thanks! :) Remember to +1 the patch on Qt's gerrit if you agree with it.

It seems the patch is not upstreamed yet.

It was retargeted for Qt 5.4 and is currently stuck in staging/review: https://codereview.qt-project.org/#/c/96948/

Lots of unrelated CI failures ...

Fixed in QT 5.4 https://qt.gitorious.org/qt/qtbase/commit/c493546a0a1bbf1455f67092364bdba18e43ba01