And that's great. But then please argue/describe from practice, and not from some largely mythical fundamental differences in programming model that only confuse. That would be really helpful, thanks.
> layout and text measurement
Yup, as I mentioned, the text APIs in Cocoa/CocoaTouch/Quartz are so rancid that just slapping on a TextLabel is incredibly more convenient, despite the fact that you get horrible messy subview soup (I like that term, can I borrow it?).
The solution would probably be better text APIs. Which are actually not that hard to build.
(Alas, the text stuff in particular is only partially complete, I had more important projects. The very rough idea is to be able to essentially printf() into a view)
> drawRect [..] only specifies rendering.
Yep.
> But UIs usually care about local state
Right, that's why drawRect is embedded into these things called Views, which have local state.
> Especially in lists.
Right. And you have easy-to-use Views like NSTableView that handle lists beautifully, without you having to worry about the active set of subviews. Essentially you give it a data source and it will ask the data source about what it needs, when it needs it. Meaning it can handle arbitrarily large/infinite lists without problems. There are layers of customizability, from just delivering data via specifying cells to customise drawing/interaction all the way to having the NSTableView use arbitrary subviews to represent rows/columns.
And that's great. But then please argue/describe from practice, and not from some largely mythical fundamental differences in programming model that only confuse. That would be really helpful, thanks.
> layout and text measurement
Yup, as I mentioned, the text APIs in Cocoa/CocoaTouch/Quartz are so rancid that just slapping on a TextLabel is incredibly more convenient, despite the fact that you get horrible messy subview soup (I like that term, can I borrow it?).
The solution would probably be better text APIs. Which are actually not that hard to build.
https://github.com/mpw/DrawingContext
(Alas, the text stuff in particular is only partially complete, I had more important projects. The very rough idea is to be able to essentially printf() into a view)
> drawRect [..] only specifies rendering.
Yep.
> But UIs usually care about local state
Right, that's why drawRect is embedded into these things called Views, which have local state.
> Especially in lists.
Right. And you have easy-to-use Views like NSTableView that handle lists beautifully, without you having to worry about the active set of subviews. Essentially you give it a data source and it will ask the data source about what it needs, when it needs it. Meaning it can handle arbitrarily large/infinite lists without problems. There are layers of customizability, from just delivering data via specifying cells to customise drawing/interaction all the way to having the NSTableView use arbitrary subviews to represent rows/columns.
https://developer.apple.com/documentation/appkit/nstableview...
No new programming model required, just a view within the current programming model.
And of course if you create your own views, they handle both the drawing (drawRect) and the interaction.
https://developer.apple.com/documentation/appkit/nsview?lang...