如何使窗口缩放尊重自动布局约束？
为了使事情变得简单，假设我有一个包含单个视图的窗口，该视图具有自动布局约束，将所有4个侧面绑定到窗口容器视图，并假设此视图还具有约束，将其纵横比设置为常数价值。如果我手动调整窗口大小，则可以很好地维护所需的长宽比。但是，如果我单击小绿色缩放小部件，那么无论纵横比如何，窗口都会填充整个屏幕，其中一部分视图位于屏幕顶部上方。有没有某种方法可以使Zooming尽可能大，而不会违反自动布局约束？
我不能很好地在委托方法windowwillesize中检测到这个问题：tosize：，因为这并不能告诉我它正在考虑要戴上窗口的屏幕。我可以尝试在WindowDidizize：委托方法中修复窗口大小，此时我确实知道它在哪个屏幕上，但是我不确定在不重新发明自动布局的车轮的情况下如何执行此操作。
显然有人认为我不够明确，所以我会再试一次。复制的步骤：
- 在XCode中，使用XIB接口创建一个新的MacOS应用程序项目。
- 打开mainmenu.xib并选择窗口。
- 重塑窗口大约是正方形的。
- 使用属性检查器，将窗口的全屏幕行为设置为辅助窗口。
- 从库中拖动图像视图并将其放在窗口中。
- 在“属性检查器”中，设置图像视图以独立显示NSComputer图像和比例轴。
- 展开图像视图以填充窗口内容区域。
- 选择图像视图时，单击按钮添加新的布局约束。
- 添加5个约束，将4个侧面结合到容器中，并设置纵横比。 （请参阅屏幕截图）
- 构建和运行。
- 观察到，如果通过拖动边缘或角来调整窗口大小，则纵横比保持固定。
- 单击窗口标题栏中的绿色缩放小部件，并观察窗口会扩展而不考虑纵横比约束，切断图像的一部分。
To keep things simple, let's say I have a window containing a single view, which has auto layout constraints binding all 4 sides to the window container view with offset 0. And assume that this view also has a constraint setting its aspect ratio to a constant value. If I resize the window manually, then then window nicely maintains the desired aspect ratio. But if I click the little green zoom widget, then the window fills up the whole screen, regardless of the aspect ratio, with part of the view being above the top of the screen. Is there some way I can make zooming resize the window as big as it can be, without violating auto layout constraints?
I couldn't very well detect this problem in the delegate method windowWillResize:toSize:, because that doesn't tell me which screen it's thinking about putting the window on. I could try to fix the window size in the windowDidResize: delegate method, at which time I do know what screen it's on, but I'm not sure exactly how to do that without reinventing Auto Layout's wheel.
Apparently someone thinks I wasn't explicit enough, so I'll try again. Steps to reproduce:
- In Xcode, create a new macOS App project using XIB interface.
- Open MainMenu.xib and select the window.
- Reshape the window to be approximately square.
- Using the Attribute Inspector, set the Full Screen behavior for the window to Auxiliary Window.
- Drag an Image View from the library and drop it in the window.
- In the Attributes Inspector, set the image view to show the NSComputer image and scale axes independently.
- Expand the image view to fill up the window content area.
- With the image view selected, click the button to add new layout constraints.
- Add 5 constraints, binding the 4 sides to the container, and setting the aspect ratio. (see screen shot)
- Build and Run.
- Observe that if you resize the window by dragging an edge or corner, the aspect ratio remains fixed.
- Click the green zoom widget in the title bar of the window, and observe that the window expands without regard for the aspect ratio constraint, cutting off part of the image.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我只是按照您的指定设置了一个测试项目，当我调用窗口缩放小部件时，窗口会扩展并保留其纵横比，即它可以按预期工作。我唯一能想到的可能是导致您的问题：也许您的内容拥抱和内容压缩性优先级与您的约束不一致？请注意，我只是以默认值离开了它们，并且效果很好。不幸的是，Mac/AppKit开发（尤其是使用IB时）充满了这种奇怪的错误和怪异的行为，这可能是因为Apple多年来没有给予任何爱，所以Bugs蔓延到/Fester中，并且显然是在开发开发的情况下完成的。 UI是“老式的方式”。 （使用SwiftUi以不同的方式制作Mac应用程序同样令人沮丧，因此我会坚持我所知道的）。仅供参考，我使用Xcode 13.4.1创建此测试项目。祝你好运！
I just set up a test project exactly as you specified, and when I invoke the window zoom widget, the window expands and retains its aspect ratio i.e. it works as expected. The only thing I can think of that might be causing your issue: maybe your content hugging and content compression resistance priorities are at odds with your constraints? Mind you, I just left them at the default values and it worked fine. Unfortunately Mac/AppKit development (esp. when using IB) is rife with these kind of odd bugs and weird behaviour, probably because Apple has not given it any love in years, so bugs creep in/fester and they are clearly so DONE with developing UI the 'old fashioned way'. (Using SwiftUI to make a Mac app is just as frustrating, in different ways, so I'll stick with what I know). FYI, I used Xcode 13.4.1 to create this test project. Good luck!