Text Tools Wireframes
OpenPublic

Mock History

Current Revision68

Mock Description

Text Tools Update for Krita

Hi, @scottpetrovic!

Your wireframes are really nice, especially the idea with hyperlinks for opentype! :)

The main problem for me atm is the way how we are going to edit the text that is embedded into a shape. We need to be able to edit properties of both: the text and the enclosing shape. How can we do it without having a dedicated tool?

We can introduce some kind of "selection inside group", which will automatically select both objects: the text and the shape, but I'm not sure how it should work...

Inline Comments

Do these options apply to the currently selected paragraph or to the entire text frame? I guess paragraph would be a sane approach, though a bit more complex

Kerning and Letter spacing can be applied to specific letters only, so, conceptually, they are a part of "Character style", but I'm perfectly ok with keeping them here. Just would like to here if everyone else agree with it :)

Here is a small problem:

We are able to put the text onto any type of shape. Therefore one should also be able to edit the shape itself, therefore it needs all the usual options of the selection tool.

I see two solutions:

  1. Make the text inside shape selectable by itself. But I'm not sure how easy it is. When rearranging the shapes, this selected text but interfere with user's actions.
  2. Revert back to the idea of editing text on shape with a dedicated text tool.

Probably, some other solution exists as well.

Ligatures are basically a list of checkboxes, where you can select a subset of ligatures you need. Do you mean that the Combo Box here will have the boxes inside?

Selecting the features to configure/activate is a very good idea! I even understand why you don't use a usual listbox for that, it take too much space.

As far as I understood, this is a label with "hyperlinks" that activate the corresponding features. Right?

I wonder, is it possible to align the hyperlinks somehow nicely?

I'm perfectly ok with dropping them :)

Typically, programs that have text-on-path and text-flowed-in-shape have the shape and the path as separate objects to be edited. I think this conforms to the structure of svg as well? So perhaps the shape that a text object needs to interact with should just be selectable from the canvas and be manipulated there?

Speaking of which, text-on-path is not possible with multi-line text while text-flowed-in-shape is implicitly multiline. Perhaps it might be an idea later to turn this interaction as a toggle? (Though, then, pre-formatted text becomes an issue of it's own)

Adding a little note.

Inline Comments

@rempt and I have noticed that we can show rich text version of the text just fine within a little editing box. We can also convert this quite easily to html. We won't have to do bbcode style markup then :)

We're gonna experiment with that today.

Some added thoughts. The NB are more technical notes for @dkazakov and @rempt than commentary on the design.

Inline Comments

We can reuse the KDE Frameworks glyph widget :D

This should be called 'padding'. Margin is outside the frame, padding is padding on the frame before the text is poured in.

We were wondering whether it wouldn't be more sensible to use styles for this, but that might need a better consideration of how the style workflow should work out.

Added to that, should the size unit be in pt, or px, or do we hope for Jospin's unitspinboxes to be fixed then? :P

Copy/Paste/Cut/Undo/Redo seems to be missing here? Better to have dedicated buttons for that, in case we cannot make the shortcuts play nice.

We also weren't sure how necessary Lists would be. Sure, we can render them, but is it necessary?

NB: Line-spacing isn't mentioned in the Qt supported css features, but it is in qt 4.8+

NB: We will need to fork QTextLayout if we wish to support top-top-bottom.

If we want to conform to CSS/SVG2, This would be a total of 5 buttons:
Flow: Horizontal top-to-bottom, Vertical Left to Right, Vertical Right to Left.
And then, on top of that Direction left-to-right, and right-to-left.
The spec considers the first 3 the main flow, and the last 2 whether it goes against the grain or not... It's a very silly, but backwards compatible spec.

NB: while QFont supports letterspacing, wordspacing, kerning,(and stretch, and capitalisation), the QCss Parser doesn't understand those values in css.

Deevad added a subscriber: Deevad.Apr 7 2017, 2:00 PM

@woltherav good points. I think some of this will be getting things close to the UI -- but it is only a guideline. There will probably have to be somethings slightly different when they start getting implemented.

Good point on margin/padding. That should be padding.

We can definitely modify or add buttons like copy/paste/redo. I just pulled some of the existing options from the existing text tool.

I am not sure about moving the font options to a styles area. Font family, font size, and color are probably the most heavily used options when adding text. A lot of the time people don't need styles too, so it is kind of an advanced feature. I would not put them in another area, but maybe someone else has an opinion on it