I could really use some help with macOS UI work for this Mastodon client I'm working on. I'm struggling ridiculously with the core concept of NSTableView cell resizing.
Please boost.
I could really use some help with macOS UI work for this Mastodon client I'm working on. I'm struggling ridiculously with the core concept of NSTableView cell resizing.
Please boost.
@eurasierboy ahhh doing it in iOS is so much easier though, ahahaha. The Cocoa API has not only been left to rot, but is badly documented as well, and actually has broken parts since it "evolved" that nobody has documented either.
Some things like "intrinsic height doesn't work unless you do view.stringValue = view.stringValue before checking it" is seriously voodoo nightmares.
I think, as in iOS UITableView, you would use implement NSTableViewDelegate with tableView(_:heightOfRow).
https://developer.apple.com/reference/appkit/nstableviewdelegate/1529684-tableview
I'm sure you probably have already found this, but Ray Wenderlich has a NSTableView tutorial here:
https://www.raywenderlich.com/143828/macos-nstableview-tutorial
@erico it doesn't behave as it's documented at all, as it was designed before auto-layout was implemented, and they interact in such insane ways you need to be really in tune with the intricacies to get it to work consistently.
I have it "working", but it doesn't work properly on resize, and some toots will be the wrong size for no reason, while others are fine...
@erico also NSTableView does not support the premise of estimated heights and UITableViewAutomaticDimension.
I've found hacks that try to implement this, but none of them work in the general case, and it's driving me totally insane!
@erico I appreciate the feedback but I have also searched for this for the last almost two weeks in Google as well, and tried very many things, lol.
The problem is that height measurement is so very inconsistent none of these approaches work, as I have no fucking idea what the random lifecycles are that are fighting each other.
@charlag don't buy into that lie. Kotlin nullable types are real in Kotlin, as much as Swift nullable types are real in Swift.
Objective C can break those constraints just as well as Java can in Kotlin.
@charlag I thought that might be what you are saying, but I can't think of the use case.
If you really need that you can just do this:
fun String.optional(): String? {
return this
}
@piecritic there was one case when I wanted to use Rx like that
someNetworkRequest()
.map { Optional(t) }
.onErrorJustReturn(nil)
.filter { it != nil }
but I had to go with something like
.onErrorResumeNext(Observable.empty())
@charlag why were you passing an optional out of a map? I usually use flatMap to get _rid_ of optionals in Rx.
In RxSwift, RxOptional's filterNil.
@charlag btw, Kotlin is going native, targeting LLVM and planning to natively support Objective C libraries, so Kotlin for iOS is coming soon!.
https://blog.jetbrains.com/kotlin/2017/04/kotlinnative-tech-preview-kotlin-without-a-vm/
@charlag there isn't actually all that much crossover with iOS UIKit and Cocoa AppKit.
Superficially yes, but in practice everything is actually hell.