@ctietze As far as I can tell the wobble is due to the windowResizability setting not positioning the content correctly for a frame here and there. It fixes it on the next frame but it is frustrating it's not smooth.
All the SwiftUI views inside resize smoothly on their own.
@isaiah@ctietze I'm not sure how you'd ensure all three buttons are the same width with just autoresizing, but yeah, you could get there with that and maybe one override of -resizeSubviews:withOldSize:
@bwebster@ctietze it takes a few subviews. but subviews are cheap. i do this with all the Stacks sidebar controls.
if you want fixed size buttons, or resize with the window, it’s all IB.
if you want the buttons to resize with the content of their text labels then i usually take care of that in the view’s layout method — resizeSubviews works for most things too.
or i add a subview that uses autolayout just for content resizing — this reigns in some of the autolayout complexity IMHO.
@ctietze@bwebster the example chooses some things that are easy-ish in autolayout, but perhaps not great from the user experience or aesthetic viewpoint.
if it were me setting this up i would personally choose non-resizing OK and Cancel buttons and let the other one resize.
and then a reasonable min-sized window to allow most content without truncating.
this is perhaps less general and less flexible but it feels IMHO factored a bit more correctly for the real world.
@ctietze@bwebster
for what it's worth, i didn't read the details until i began. my bad -- i apologize. there is, of course, no way to build a UI that changes with content using springs and struts. it's all top-down constraints.
that said, here's my quick UI:
keeps the buttons the same size.
maintains correct spacing.
margins don't scale, just buttons.
there's not much to it, so it went pretty fast.
to make this more general i would need to amend with autoconstraints or code.
@ctietze@bwebster i'm the last person to take the side of SwiftUI -- i'm not a fan. and it's especially terrible on macOS.
but i'm going to side with SwiftUI here… 😬
i think part of the challenge is in trying to do something where autoconstraints tends to ignore a slightly ambiguous situation -- that other systems instead make more pronounced.
it's like telling your doctor, "it hurts when i bend my arm backwards," and your doctor replies, "then don't bend your arm backwards."
@ctietze@bwebster
starting with the buttons the same size -- yet also have a minimum intrinsic size leads to a slightly ambiguous constraint.
it's conceivable that "A Lot of Text" starts out larger than the initial same-sized buttons. which constraint is more important: same size or the min size?
it's not difficult to overcome this of course -- my point is simply that by contriving a situation where autoconstraints glosses over a detail, the test is liable to produce results that misinform.
@ctietze Here’s my best effort.
Everything but the window resizing took about 8 minutes.
I wasn't quite sure how the window stuff works on Mac, and it took at least another 15 minutes to figure how it works and to get at least a viable solution.
Sadly, the way windowResizability works makes it impossible to implement this without a GeometryReader or a Layout, and even then it's a bit janky. SwiftUI needs something like the compression resistance priority here.
@ctietze Debating whether SwiftUI is “production-ready” in 2024 is an eye-roll argument, though. It has, limitations, sure, but what doesn't? It's just cherry-picking examples and moving the goalposts once those specific issues are resolved.
Today I’d say SwiftUI has its pros and cons. I still doubt that it is better than UIKit/AppKit. It’s (just) different.
I like the good things about Autolayout more than I like the good things in SwiftUI. And I hate the bad things in SwiftUI passionately while I have made peace with the bad things in UIKit.
(We all thought Autolayout errors were the worst possible …)
@teilweise I still don't understand why people, who wrote bad UIKit code, think that they'll suddenly start writing good code because of SwiftUI.
SwiftUI has worse debugging experience. View debugger doesn't show custom view names. Initializers (inside a view builder?) are often called from a bunch of unnamed symbols that don't relate to your code. This makes joining an ongoing project much less frictionless.
@Cyberbeni Maybe they think their code was bad because of UIKit? Plus the marketing of SwiftUI that lets them think most things will automagically just work.
SwiftUI doesn’t make things worse if AutoLayout errors too are totally cryptic for you.
I don’t know. For me, SwiftUI is more of a black box than UIKit. Handling black boxes is hard, especially if they are poorly documented and/or behave in unexpected ways (not least: bugs).
Add comment