Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TextKit 2 – The Promised Land

blog.krzyzanowskim.com

Post reply on HN
Print view View original

11–20 of 33 posts

Re: TextKit 2 – The Promised Land

#11

Post by krzyzanowskim »

colbyn wrote: post #10
colbyn wrote: post #9

Oh hey good to see some more literature on TextKit2. I remember diving into it when I wrote my proof of concept markdown renderer: https://github.com/SuperSwiftMarkup/SuperSwiftMarkdownProtot... It’s a good example of what else you can do with TextKit2, beyond plain text rendering. Here, I can draw text layout fragments in a core graphics context and use typographic information to also render markdown specific graphi…

Oh also I’d like to add to the above, the TextKit2 API is way more freeform than people think. You could probably implement your own web browser upon it with optimized line by line text rendering (which isn’t that bad). One thing I always wanted to experiment with is rendering markdown content with horizontally scrollable text fragments for table rows and certain fenced code blocks. Super cool and practical idea for…

we could build a space rocket with it if we only knew how to use it, so it would not glitch

Re: TextKit 2 – The Promised Land

#12

Post by rayiner »

lapcat wrote: post #4
arthurofbabylon wrote: post #2

> TextKit2 is implemented to be used by UITextView This is the key insight that makes TextKit2 workable. I personally would not attempt to build an alternative to UITextView on TextKit (1 or 2). Instead, TextKit2 is all about very sensible intervention points for customizing UITextView (eg, Markdown-style parsing, typography, interactions, layout). I recently rebuilt Minimal’s editor with TextKit2 (see minimal.app/#b…

> I would not dismiss TextKit2; it is an incredible improvement over TextKit1. It's an absolute disaster on macOS. Even TextEdit app is now buggy as hell. It's incredible how Apple broke plain text display on the Mac, which was a solved problem since forever.

Is it incredible, or is it quite credible? It’s taken Microsoft years now for “New Outlook” to get feature priority with Outlook 98. This feels like the new normal.

Re: TextKit 2 – The Promised Land

#13

Post by andrekandre » 

  > Today, I believe that's not me. The TextKit 2 API and its implementation are lacking and unexpectedly difficult to use correctly. While the design is solid, it proved challenging to apply in real-world applications.
when making new apis its a good idea to have people try and use it like this to find and fix the rough edges and fix bugs... it definitely feels like apple didn't do that (at least enough) here...

Re: TextKit 2 – The Promised Land

#14

Post by nicoburns »

colbyn wrote: post #10
colbyn wrote: post #9

Oh hey good to see some more literature on TextKit2. I remember diving into it when I wrote my proof of concept markdown renderer: https://github.com/SuperSwiftMarkup/SuperSwiftMarkdownProtot... It’s a good example of what else you can do with TextKit2, beyond plain text rendering. Here, I can draw text layout fragments in a core graphics context and use typographic information to also render markdown specific graphi…

Oh also I’d like to add to the above, the TextKit2 API is way more freeform than people think. You could probably implement your own web browser upon it with optimized line by line text rendering (which isn’t that bad). One thing I always wanted to experiment with is rendering markdown content with horizontally scrollable text fragments for table rows and certain fenced code blocks. Super cool and practical idea for…

> You could probably implement your own web browser upon it with optimized line by line text rendering

I actually have an ambition to do this. I already have most of the layout engine. The use case is for a React Native like framework that can render spec-compliant web content.

Re: TextKit 2 – The Promised Land

#15

Post by zffr »

andrekandre wrote: post #13

> Today, I believe that's not me. The TextKit 2 API and its implementation are lacking and unexpectedly difficult to use correctly. While the design is solid, it proved challenging to apply in real-world applications. when making new apis its a good idea to have people try and use it like this to find and fix the rough edges and fix bugs... it definitely feels like apple didn't do that (at least enough) here...

Apple’s typical process for releasing public API involves dogfooding it internally first. Sometimes it will take years of internal use before Apple will release API publicly.

With something as large as TextKit, I would be extremely surprised if Apple did not get several of its apps to adopt the new API and use it for a few years before considering releasing it publicly.

Re: TextKit 2 – The Promised Land

#16

Post by whoisthemachine »

This is an unavoidable result of lazy layouts. With the LazyList in Jetpack compose, it's comically difficult to produce a scrollbar, because the "LazyList" only ever lays out the visible items, so Compose can't really know (unless you actually already know) the full size of the list.

I find the iron triangle of project management reins supreme in a lot of domains: quality is sacrificed in the name of performance.

[0] https://en.wikipedia.org/wiki/Project_management_triangle

Re: TextKit 2 – The Promised Land

#17

Post by wpm »

zffr wrote: post #15
andrekandre wrote: post #13

> Today, I believe that's not me. The TextKit 2 API and its implementation are lacking and unexpectedly difficult to use correctly. While the design is solid, it proved challenging to apply in real-world applications. when making new apis its a good idea to have people try and use it like this to find and fix the rough edges and fix bugs... it definitely feels like apple didn't do that (at least enough) here...

Apple’s typical process for releasing public API involves dogfooding it internally first. Sometimes it will take years of internal use before Apple will release API publicly. With something as large as TextKit, I would be extremely surprised if Apple did not get several of its apps to adopt the new API and use it for a few years before considering releasing it publicly.

I’m sure they did, but did they actually fix all of the bugs they found?

Re: TextKit 2 – The Promised Land

#18

Post by bobbylarrybobby »

whoisthemachine wrote: post #16

This is an unavoidable result of lazy layouts. With the LazyList in Jetpack compose, it's comically difficult to produce a scrollbar, because the "LazyList" only ever lays out the visible items, so Compose can't really know (unless you actually already know) the full size of the list. I find the iron triangle of project management reins supreme in a lot of domains: quality is sacrificed in the name of performance. [0…

While difficult, there are surely ways to make the scroll bar move more smoothly. For instance, you could demand that it can only change direction when the scroll direction changes. You can also use past scroll bar positions as stronger estimates of document height than text content and whatever else is being used, which would lead to more consistent (if inaccurate) scrolling as well. But as long as we're estimating things we might as well make them enjoyable to use; it's not like the user will be able to discern that the scroll bar is off by 5% anyway.

Re: TextKit 2 – The Promised Land

#20

Post by eviks »

> The jiggery is super annoying and hard to accept. This is also expected, given that the height is estimated. Works as-designedj

It works as poorly designed, but it's not expected. You don't need to show those tiny meaningless jumps to the user since no user action will be different based on this extra precision, the scrollbar indicator is just not that kind of tool.

Post reply on HN