Styled Text: add a macro and functions for parsing markdown #10060

expenses · 2025-11-13T15:26:58Z

No description provided.

expenses · 2025-11-14T16:40:43Z

Currently getting this error:

thread 'main' (84556) panicked at internal/interpreter/dynamic_item_tree.rs:1103:25:
Native type not registered: StyledText

@ogoffart where should I be registering this?

internal/compiler/builtins.slint

internal/core/lib.rs

ogoffart · 2025-11-17T09:37:26Z

internal/core/lib.rs

+    out
+}
+
+pub fn parse_markdown(text: &str) -> std::string::String {


The idea is that this function should return a slint::StyledText

ogoffart · 2025-11-17T09:40:48Z

Native type not registered: StyledText

This is supposed to be registered in

slint/internal/interpreter/dynamic_item_tree.rs

Line 985 in b478a94

rtti_for::<MarkdownText>(),

expenses · 2025-11-17T09:44:16Z

Native type not registered: StyledText

This is supposed to be registered in

slint/internal/interpreter/dynamic_item_tree.rs

Line 985 in b478a94

rtti_for::<MarkdownText>(),

Ohh, right, thanks. Part of the confusion here is that we have both component StyledText and property <styled-text> and they both correspond to rust structs of the same name

ogoffart · 2025-11-17T11:12:38Z

Part of the confusion here is that we have both component StyledText and property and they both correspond to rust structs of the same name

Indeed. It is possible to have the item have a different struct name. For example Window vs WindowItem
So you can rename the struct in rust to StyledTextItem and in builtins.slint have export StyledTextItem as StyledText

tronical

Looking overall good! :). I hope it's not too early to provide comments, but I've added some inline. I think besides those comments the main thing I see missing are tests (in tests/cases). I wonder if it's possible to do for example a link-click test with the testing backend.

Edit: I guess C++ is missing as well, but that's follow-up material perhaps?

tronical · 2025-11-20T07:04:08Z

internal/compiler/parser/expressions.rs

    p.expect(SyntaxKind::RParent);
 }

+fn parse_markdown(p: &mut impl Parser) {


Please add some basic tests to this function. You can see with parse_tr() right above that there's a framework for that. That way we can catch any future refactoring mistakes earlier.

And also test errors in similar in a syntax test, similar to internal/compiler/tests/syntax/basic/tr.slint and tr2.slint
https://github.com/slint-ui/slint/blob/master/docs/testing.md#syntax-tests

tronical · 2025-11-20T07:07:39Z

internal/core/api.rs

 }
+
+#[derive(Clone, Debug, PartialEq)]
+#[allow(missing_docs)]


To be addressed in scope of this PR or afterwards? :)

tronical · 2025-11-20T07:08:37Z

internal/core/api.rs

+    ClosingTagMismatch(&'a str, std::string::String),
+}
+
+/// Internal styled text type


By this (and the other types) being placed here and being pub, they're not internal anymore but public API.

I sugest to make StyledText public, but its fields as well as the other associated types pub(crate), so that the public API surface is basically

#[non_exhaustive] pub enum StyledTextError { ... } pub struct StyledText { .. } impl StyledText { pub fn from_markdown(markdown: &str) -> Result<Self, StyledTextError> { ... } pub fn from_plaintext(plaintext: &str) -> Self { ... } }

@expenses @ogoffart what do you think? (We can also have a call to discuss the API surface, if it's more than that)

tronical · 2025-11-20T07:10:41Z

internal/core/api.rs

+#[cfg(feature = "experimental-rich-text")]
+#[derive(Debug, thiserror::Error)]
+#[allow(missing_docs)]
+pub enum StyledTextError<'a> {


This enum should be non_exhaustive, I think.

ogoffart

Note that this PR is becoming big and i wonder if it wouldn't be beneficial to split some part like renaming "MarkDownText" or adding "styled-text" type in their own PR. (But only if it is easy to do and make things faster, not if it makes things slower)

ogoffart · 2025-11-20T08:07:06Z

internal/compiler/parser/expressions.rs

    p.expect(SyntaxKind::RParent);
 }

+fn parse_markdown(p: &mut impl Parser) {


And also test errors in similar in a syntax test, similar to internal/compiler/tests/syntax/basic/tr.slint and tr2.slint
https://github.com/slint-ui/slint/blob/master/docs/testing.md#syntax-tests

ogoffart · 2025-11-20T08:10:24Z

internal/compiler/typeregister.rs

        register.types.remove("DropEvent").unwrap(); // Also removed in xtask/src/slintdocs.rs

-        register.elements.remove("MarkdownText").unwrap();
+        register.elements.remove("StyledText").unwrap();


If we want to keep the feature internal, we also need to remove the "styled-text" from register.types

ogoffart · 2025-11-20T08:12:46Z

internal/core/api.rs

+#[derive(Debug, PartialEq, Clone, Default)]
+#[allow(missing_docs)]
+pub struct StyledText {
+    #[cfg(feature = "experimental-rich-text")]


imho the full struct should be gated.

ogoffart · 2025-11-20T08:15:48Z

internal/core/api.rs

        |ctx| ctx.set_xdg_app_id(app_id.into()),
    )
 }
+


Perhaps this whole thing should be in its own module.
api.rs is already quite big.

it should either go to core/styled_text.rs or core/api/styled_text.rs
And everything should be gated with experimental-rich-text for now.

ogoffart · 2025-11-20T08:17:06Z

internal/core/lib.rs

        debug_log!("Error opening url {}: {}", url, err);
    }
 }
+


And this should also go to the styled_text module

ogoffart · 2025-11-20T08:19:45Z

internal/core/lib.rs

    }
 }
+
+pub fn escape_markdown(text: &str) -> alloc::string::String {


Note that this depends on where in markdown this goes.
If you have something like:

``` {} ```

then you need another way to escape.

I wonder if that kind of escaping make sense at all, and maybe it would be best to do the interpolation on our internal data structure after the parsing.

ogoffart · 2025-11-20T08:22:59Z

internal/core/software_renderer.rs

            }
+            (_, true, PlainOrStyledText::Styled(_))
+            | (fonts::Font::PixelFont(_), _, PlainOrStyledText::Styled(_)) => {
+                panic!("Unable to get text size of styled text without parley")


We have to discuss as well how to handle this. For example for Path, we just ignore it and not draw it, same for transformation. So I guess we have to do the same, or just draw the text without style.

expenses requested review from ogoffart and tronical November 14, 2025 16:48

ogoffart reviewed Nov 17, 2025

View reviewed changes

expenses force-pushed the markdown-macro branch from 4e9e4bc to b6d3eb8 Compare November 17, 2025 12:45

expenses and others added 10 commits November 17, 2025 16:29

Add markdown macro and parse/escape functions

769d439

Markdown stuff

866dcf1

Implement escape markdown, handle trailing literal sections

374e2b6

add StyledText Type and Value

4923354

Implement more things

bb2a927

[autofix.ci] apply automated fixes

3c72c1c

Rename MarkdownText to StyledText

f3242c8

Add comments and solve warnings

91f4517

Apply automated fixes

e72f523

Fill out styled text type

ff8b450

expenses force-pushed the markdown-macro branch from a7a2ff7 to ff8b450 Compare November 17, 2025 15:33

expenses added 5 commits November 18, 2025 14:55

Change rendertext trait to use enum

0220097

Add allow missing docs to stuff

d2fc4b5

Fix testing backend thing

70bb110

Move test

9cca35a

Don't use std:: for certain types

3184132

expenses marked this pull request as ready for review November 18, 2025 17:40

expenses and others added 5 commits November 18, 2025 18:56

Fix api/node

264527c

[autofix.ci] apply automated fixes

aa66898

Merge with master

c35913a

Rename to StyledTextItem

8a9bfcf

Ignore styledtext in cpp for now

feac54a

expenses requested a review from ogoffart November 19, 2025 19:42

tronical reviewed Nov 20, 2025

View reviewed changes

ogoffart reviewed Nov 20, 2025

View reviewed changes

expenses mentioned this pull request Nov 20, 2025

Add StyledText type #10122

Merged

Merge with master

b004797

expenses force-pushed the markdown-macro branch 2 times, most recently from 229a0c2 to b004797 Compare November 21, 2025 14:20

Remove whitespace change

bce8665

Styled Text: add a macro and functions for parsing markdown #10060

Are you sure you want to change the base?

Styled Text: add a macro and functions for parsing markdown #10060

Conversation

expenses commented Nov 13, 2025

Uh oh!

expenses commented Nov 14, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ogoffart commented Nov 17, 2025

Uh oh!

expenses commented Nov 17, 2025

Uh oh!

ogoffart commented Nov 17, 2025

Uh oh!

tronical left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ogoffart left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

tronical left a comment •

edited

Loading