Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-41640

ibus plugin badly maps text attributes to QTextCharFormat

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P3: Somewhat important
    • Resolution: Done
    • Affects Version/s: 5.3.2
    • Fix Version/s: 5.4.0
    • Labels:
      None
    • Environment:
      OS: Fedora 21
      ibus: 1.5.9
      ibus-hangul: 1.4.2
      Qt: 5.3 branch tip

      Description

      When I am typing a Hangul block into a Qt 5 app using ibus, 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.

        Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            People

            Assignee:
            paeglis Gatis Paeglis
            Reporter:
            hein Eike Hein
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Gerrit Reviews

                There are no open Gerrit changes