Skip to content

Draft: Add glyph palette

This adds a QML driven glyph palette to the text tool. It can do 2 things: firstly, it can show a character map of the given font, secondly, it can present both glyph alternates and variation selectors. While there will be toggles for opentype features as well, a glyph palette can be the most intuitive way to select these.


This is an exercise in using QML as well. Most of the important stuff (model views, models) is part of QDeclarative. The Qtquick.layout and QtQuick.controls are part of QtQuickControls2 in Qt 5.15 and shift to also being part of QDeclarative in qt 6. I am making this MR because I am having trouble with getting Qt quick controls to adopt the theme, even though all the other QML elements are using it, if it appears that these are unthemable in qt 5.15, I think I might need to switch to Krita's internal old sketch components.


  • Use unicode blocks instead of scripts for filtering, this will require generating a blocks file from UCD text file.
  • Allow filtering by string.
  • Improve tooltips
  • Improve harfbuzz glyph retrieval code.
  • Docs

Test Plan

Test the glyph palette by editing a text with a font that uses opentype features:

  1. The demo uses MonteCarlo from google fonts, another good test font is Junicode, which has tons of alternate glyphs, but even Noto Sans has small caps.
  2. For variation selectors, you can try Source Han or Noto Sans CJK, 邉󠄀 (edge) is the character with the most variation selectors.

Formalities Checklist

  • I confirmed this builds.
  • I confirmed Krita ran and the relevant functions work.
  • I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
  • I made sure my commits build individually and have good descriptions as per KDE guidelines.
  • I made sure my code conforms to the standards set in the HACKING file.
  • I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.

Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build. If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list,

Edited by Wolthera van Hövell

Merge request reports