Split character and paragraph properties into two separate textData.
Experimental MR to see if splitting paragraph and character textdata into two separate textdata is more user-friendly.
Current 5.3 pre-alpha
- Shape Select Tool edits paragraph properties on all selected text shapes.
- Text tool edits paragraph properties when there's no selection.
- Text tool edits character properties when there is a selection.
- The Direction property is disabled in the character properties when there's no selection and invertedly enabled in the paragraph properties.
- Upsides:
- There's only one set of widgets, in theory, which makes style presets a little more straightforward.
- Downsides:
- I really don't like how we're handling direction.
- It is very different from how, say, LibreOffice handles text properties.
This MR
The main difference here is that paragraph properties will show all properties for the paragraph (including fontsize, etc), while character will only show properties on the character.
- Shape Select Tool edits paragraph properties on all selected text shapes. Character properties are disabled.
- Text tool can edit either depending on which tab you're in. If there's no selection, the character properties will be edited on a word, similar to LibreOffice.
- When setting the fill and stroke color with any of the color selectors, no selection means setting it on the paragraph, while any selection sets it on that selection.
- Style presets will be set on the character when there's a selection only, on the paragraph otherwise.
- Upsides:
- It should be clearer now how the inheritance thing works.
- Direction property is less convoluted.
- It is nicer for style presets to be able to combine, say, an alignment, font size, render settings and indentation into one preset.
- Downsides:
- The character properties are disabled when shape selection tool is used. This might be very unclear, and I worry it is going to cause frustration.
- Similarly, there's no way for us to magically determine whether paragraph or character tab should be visible. Should we have some kind of auto switch here when there's a selection, or just leave it alone?
Test Plan
- Make a text.
- Select some text.
- User the text properties docker to edit properties on paragraph and character.
- Determine if this is more user-friendly than using the current behaviour.
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?