Say hello to QskTextEdit

[peter-ha]

Resolves #109

[peter-ha]

differences text edit <-> text input

• no password input
• no validators etc. -> no acceptable input, no fixup etc.
• no maxLength
• no ensureVisible
• no echo mode

questions / discussion:

• Some properties from QQuickTextField are not exposed in QskTextField; was this intentional or have they just been added later? (Some are not exposed because they are part of the styling, e.g. (selection)color, alignment etc.)
  E.g.
  • int length
  • bool cursorVisible
  • QString selectedText
  • int selection[start|end]
  • bool persistentSelection
• Should we add QQuickTextEdit::SelectionMode to QskTextOptions? Or to the class itself? Or leave it out for now?
• Should we set the wrapMode to Wrap by default? It feels unintuitive otherwise...
• Do we need an error state for QskTextEdit like we have in QskTextInput?
• Should we have QskText[Input|Edit]::ActivationMode[s] in one common class?
• QskTextInput is missing canUndo() and canRedo(). Was this intentional or just forgotten (or added later to QQTextInput)?
• Shall the vertical size policy also be expanding? Preferred would mean it adjusts to the size hint, right? This might not be what we want, i.e. we don't want the text edit to grow as we type or so.
• I guess we want to allow the enter button to be entered into the text field, right? For now QQTextEdit doesn't seem to have the Qt::ImhMultiLine flag set, which results in the input method being committed.

[peter-ha]

[uwerat]

Does the elide mode make much sense here ? A text area is multi line and I would expect, that the placeholder text would be fitted into the viewport. ( -> QskTextOptions::Wrap )

[uwerat]

But wait - you are probably right. One also wouldn't expect to have to scroll the placeholder text.

[peter-ha]

Yeah, especially since it is not possible to scroll the text (just like with QML's TextArea)

[uwerat]

Code is in master now - beside the design system specific skinlets ( do we have any specific decorations ? ).

[uwerat]

Don't believe, that we need an error state - at least suggest not to implement it for the first release.

[uwerat]

I also noticed, that the API of QQuickTextInput is not exported completely. But I thought I will have a second look at them once I'm done with QskTextField and friends. F.e I wouldn't add undo/redo to a password field and where to export the related API depends on the type of controls we will have ...

[uwerat]

It is very likely, that QskTextEdit will be laid out with one dimension being fixed, while the other one grows with the text. So QskTextEditSkinlet::sizeHint needs to support heightForWidth/widhForHeight calculations.

The implementation will be similar to QskTextLabelSkinlet::sizeHint.

[uwerat]

I noticed, that it is not possible to enter newlines with the keyboard ?

[peter-ha]

I noticed, that it is not possible to enter newlines with the keyboard ?

Yeah strange, looking at the code, QQuickTextEdit enables the Qt::ImhMultiLine flag, and QskTextEdit does check for it.

I will look into it; worst case is we will have to override QQuickItem::inputMethodQuery() and return said flag.

[peter-ha]

Code is in master now - beside the design system specific skinlets ( do we have any specific decorations ? ).

Isn't that similar to the ones from the text input? I.e. for M3 we would have the label text in the border or so, for which we would need an own skinlet? I couldn't even find a text edit for M3, but I assumed we would implement it in analogy to the text fields.

[peter-ha]

I will look into it; worst case is we will have to override QQuickItem::inputMethodQuery() and return said flag.

We need something like #503 .

It turns out inputMethodHints() is sort of a user setting; when querying the hints in inputMethodQuery(), QQuickTextEdit adds the Qt::ImMultiLine flag manually, see https://codebrowser.dev/qt6/qtdeclarative/src/quick/items/qquicktextedit.cpp.html#_ZNK21QQuickTextEditPrivate25effectiveInputMethodHintsEv .