[fngjdflmdflg]

>textSelectHandleLeft, textSelectHandleRight

Done

>textColor, typeface, textColorLink, textFontWeight, textStyle

handled by TextPaint in StaticLayout/DynamicLayout. For example textColorLink is just `linkColor` from TextPaint.[0]

>text, textSize, maxLines, justificationMode, breakStrategy, hyphenationFrequency, lineBreakStyle

handled by StaticLayout/DynamicLayout

>shadowColor, shadowDx, shadowDy, shadowRadius

mTextPaint.setShadowLayer(radius, dx, dy, color);

Wow, that was so difficult. Only those that "know about UI" must be capable of such a feat?

>numeric, digits, phoneNumber, inputMethod, editable, cursorVisible, textCursorDrawable, allowUndo, inputType, imeOptions, privateImeOptions, imeActionLabel, imeActionId, editorExtras,

Only needed if you add a text editor into your text view, which I did not do.

I'm not going to go through all of these because I'm not sure exactly which side implements them (for example elegantTextHeight sound like something TextView does, but I'm not sure.) I suggest you actually sit down to read TextView before you make comments about it.

[0] https://developer.android.com/reference/android/text/TextPai...

[flutas]

> Only needed if you add a text editor into your text view, which I did not do.

> I'm not going to go through all of these because I'm not sure exactly which side implements them (for example elegantTextHeight sound like something TextView does, but I'm not sure.) I suggest you actually sit down to read TextView before you make comments about it.

Which is exactly my damn point, you expect your case to be the only one used. They have to think about EVERYONE and their use cases and how everything interacts.

Have you handled LTR text correctly, custom unicode in fonts, weird alignment issues due to accent marks?

My guess would be no, simply because you never thought of them.

[fngjdflmdflg]

>you expect your case to be the only one used

I expect the text editor to be a different component. Take a look at any other UI toolkit's text view like Swift for example:

>A view that displays one or more lines of read-only text.[0]

or QT:

>QLabel is used for displaying text or an image. No user interaction functionality is provided.[1]

In fact, even for just displaying text, I still expect rich text to be handled by a separate component. In Flutter you have RichText for example.[2] I don't know why are are confusing separating components with the components existing at all. Yes, "just displaying text" should be a simple component, because any reasonable UI toolkit will have already abstracted out all the layout code into a level bellow the user facing widgets, and the simple text component will just call into that.

>Have you handled LTR text correctly

That is handled by Layout via setTextDirection, not TextView. This is what I meant by saying you should read the code. Also I already mentioned text direction in my previous comment in this chain which I see you have not bothered to read.

>custom unicode in fonts, weird alignment issues due to accent marks?

Huh? Just read the code. TextView is not doing any of that.

>My guess would be no

All you have to do si wire up these fields from the XML input (another awful ASDK technology). That's really what TextView is meant to do: send its values to the underlying Layout and handle text selection like copy-paste. I didn't want to wire up XML that I don't need so I didn't. None of it is particularly hard.

[0] https://developer.apple.com/documentation/swiftui/text

[1] https://doc.qt.io/qt-6/qlabel.html#details

[2] https://api.flutter.dev/flutter/widgets/RichText-class.html