Default line spacing, offering input on "pain points"...?

[jeffc-dev]

I have a question and a suggestion. 🙂

Question:

There's a pretty major disparity in the default line-spacing between SwiftUI and the same text as rendered by Jetpack Compose. Has there been any thought about making the default spacing look closer to equivalent between platforms?

(SwiftUI on left, Jetpack Compose on right)

I could work around this, maybe, but SwiftUI's lineSpacing is currently still unsupported by Skip.

Suggestion:

I've been having a great time exploring Skip, and overall it's kind of incredible how far along it is at this juncture. That said, I do regularly run into a fair number of minor limitations (like the one above) that I'm 99% certain the Skip team already knows about and simply hasn't gotten around to addressing yet.

I'd post about them here, but these are usually things that are clearly marked as unsupported and I don't really want to fill GitHub issues or even this discussion area up with things that (arguably) aren't actual legitimate bugs.

It'd be nice if there were some way to signal to the Skip team where we are running across "pain points" without leaving the impression that they're particularly high priority or novel. This could help them prioritize their development toward things actual Skip users are running across most often.

Perhaps a special forum category where people can list where they're encountering limitations and offer input on what they'd like to see prioritized - but with the understanding that while this may influence the Skip team's priorities, there are no guarantees.

Thoughts?

[marcprux]

That is a pretty big disparity. Most multi-line fonts look more similar in our experimentation, but I just tried with Font.largeTitle, and the line height difference matched your screenshot. We'll prioritize getting some fix in for this. Compose doesn't have a lineSpacing equivalent per se, but it does have a lineHeight style option, so we should be able to get something working with that.

And to your broader point of feature support, we've generally tried to follow a first-come-first-serve prioritization during the early adopter period, so when issues are raised we try to tackle them as quickly as possible. A more structured approach would probably be beneficial, in order to both ensure that requests don't slip through the cracks, as well as being able to gauge the number of people who need a certain feature. We'll think about how best to do this, but in the meantime, I think the best bet is to file individual reports in skip-ui to which others can then add their comments (and workarounds).

Thanks again for both the report of the issue, as well as the suggestion.