Skip to content

Allow configuring text property visibility and some UX improvements for the text property docker.

Wolthera van Hövell requested to merge woltherav/krita:text-tool-phase-2-properties-visibility-config into master

This encompasses a number of usability tweaks:

  • It is now possible to configure when text properties are visible. By default the majority only show when relevant (when inherited or set). Some common properties (font-family, style, size) are set to 'always visible', while white-space is by default 'never visible'. This way, inexperienced typesetters will not lose the core properties, while being gently kept away from 'scary' properties like white-space. Similarly, it'll avoid endless bickering about which properties should be privileged with 'always visible', because it's now configurable.
  • When the default visibility is set to 'always visible' (and no properties are contextually visible), the "add properties" becomes a little superfluous, and thus is now replaced with a filter bar to filter the visible properties.
  • The "add property" has been made a bit more pleasant to use, with the searchbar being outside the pop-up, and typing showing the popup with filtered items. Under the hood it now makes use of a proper ProxySortModel.

Code wise, a proper configuration model and ProxySortModel have been added. The former is populated with its data from the text property QtQuickItems, and handles loading/storing data to the configuration. The latter is used for the two filtering functions just described.

Test Plan

Go into the text properties docker.

  • Use the add properties bar to search for properties.
  • Use the new configure button at the top to configure property visibility.
  • When default visibility is "always set", try using the new filter text field.

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.
  • Does the patch add a user-visible feature? If yes, is there a documentation MR ready for it at Krita Documentation Repository?

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, kimageshop@kde.org.

Edited by Wolthera van Hövell

Merge request reports