Cocoa:是否存在具有用户调整大小功能的NSView？

Question

我想要一个可以通过拖动它的右下角来调整大小的NSView,就像NSWindow一样.我希望能够将此NSView嵌入到父NSView中.在Cocoa或其任何扩展中是否有这样的组件？

Answer 1

如果你对问题有更具体的了解,我可以对答案进行更具体的说明.:-)

我所知道的并不存在这样的东西,但创造并不是非常困难.做出的决定是"谁处理绘制调整大小手柄和调整大小/拖动逻辑？"

意见处理他们自己

如果用户可调整大小的视图处理绘制夹点并响应调整大小/拖动操作本身,则必须选择是否要在视图内容上方或"在外部"绘制手柄.如果您希望把手"在外面",则"可用区域"会减少,因为您的内容必须足够插入,以便为绘制调整大小控件留出空间,这会使绘图和大小调整指标复杂化.如果您在内容上"抓取"手柄,则可以避免此问题.

容器视图处理所有子视图

另一种方法是创建一个"可调整大小的视图容器视图",它可以在任何子视图的周边绘制调整大小的夹点,并在它(容器)在其中一个夹点上接收拖动事件时通过"查看子视图"来处理拖动/调整大小逻辑区域.在这里放置逻辑允许任何类型的子视图可拖动/可调整大小,并且为您提供额外的好处,即只有一个稍重的权重视图的实例(相对于其中具有更复杂逻辑的子视图的许多实例).

基本机制

一旦你决定了,那真的只是创建你的子视图,绘图,管理NSTrackingArea实例(对于抓地区域),并响应适当的鼠标方法(向下,移动等).在每个子视图处理自己的子视图的情况下,他们将管理他们自己的跟踪区域,抓握绘图和鼠标移动,设置他们自己的框架作为响应.在容器视图为其子视图处理所有这些的情况下,它将管理所有子视图的跟踪区域并在其自身上绘制它们的夹点,并设置目标子视图的框架(并且子视图对整个事物一无所知).

我希望这有助于您至少了解可能的机制.如果我不是刚起床并开始上午咖啡,我可能会更简洁地写出来,但是你有它.:-)

编辑7年后

因为没有太多关于OP想要的细节,我给出了一个非常通用的答案,但我应该提出几点:

• 总是更喜欢它,NSSplitView如果它可以为你工作(即,如果视图彼此对齐并划分公共容器视图的空间).拆分视图可让您自定义夹点区域等,并免费为子视图执行所有操作.
• 当我写这个答案时,AutoLayout不存在,并且它使得为视图处理多个大小的子视图场景滚动自己的解决方案变得非常复杂.
• 如果你确实需要一个可以在某个容器中拖动/调整大小的UI元素,那么尽量在主视图中使用CALayers,如果可以的话,可以处理所有布局/大小调整逻辑.
• 如果您不能执行上述操作(即,可调整大小的视图包含复杂的控件和布局,有自己的NSViewController等等),请尝试混合方法(使用图层显示非选定视图的缓存图像并仅添加完整,所选项目的交互式大小子视图(或项目的子视图).
• 由于AutoLayout的复杂性,我真的不能推荐真正的可拖动子视图方法,除非它是不可避免的.如果你正在设计一个包含可移动的,相当大的东西的视图,那么最好(并且最有效)将其中的所有内容都视为负责.示例:具有大量形状的图形应用程序应具有Canvas视图,该视图表示使用的形状(以及任何GUI装饰,如大小/拖动夹点等)CALayers.这种利用图形加速,是远远高于一堆(非常耗费大量资源的)更高效的NSView子视图.所有移动/大小/选择逻辑都由"画布视图"处理,唯一的子视图可能是重叠控件(尽管如果您的Canvas本身需要包含在滚动视图中,最好使用NSScrollView为此目的允许固定叠加视图的机器).
• 如果设计一个可以绘制大量内容的视图(您应该使用图层来表示这些内容)但只允许选择一个内容,即使使用AutoLayout,添加子视图的方法也是可管理的.如果"选择编辑"的东西有许多复杂的控件在编辑时变得可见,带有视图控制器的"编辑器子视图"是有意义的,并且是可维护性的一个很好的权衡(因为视图控制器划分了所有编辑功能/ UI处理)vs容器视图的复杂性(因为一个子视图不会打破资源库并保持临时AutoLayout约束,以便在容器视图调整大小和编辑器交互期间保持其位置并不过分复杂).
• 所有这些都假定为macOS; 如果为iOS设计,肯定会向后弯曲以使用图层和新的(在撰写本文时)拖放机械,目前我知道的很少.

总之,答案是不完整的,也有点过时,所以我觉得我最初的建议并不像现在这样好.