如何隐藏 Dock 图标
我想选择隐藏 Dock 图标并显示 NSStatusItem
。 我可以创建 StatusItem,但我不知道如何从 Dock 中删除该图标。 :-/
有任何想法吗?
I want to make a preference for hiding the Dock icon and showing an NSStatusItem
.
I can create the StatusItem but I don't know how to remove the icon from Dock. :-/
Any ideas?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(7)
您可以使用所谓的激活策略:
Objective-C
Swift 4
这应该隐藏停靠图标。
另请参阅
NSRunningApplicationActivationPolicy
的文档。You can use what is called Activation Policy:
Objective-C
Swift 4
This should hide the dock icon.
See also
NSRunningApplicationActivationPolicy
.我认为您正在 Info.plist 中寻找
LSUIElement
请参阅此处有关打开/关闭它的简短讨论
I think you are looking for the
LSUIElement
in the Info.plistSee a short discussion here about turning it on/off
要执行此操作,同时遵守不修改应用程序包的 Apple 准则,并保证 Mac App Store 应用程序/(Lion 应用程序?)的签名不会因 info.plist 修改而损坏,您可以默认将 LSUIElement 设置为 1,然后当应用程序启动时执行以下操作:
显示其停靠图标,或者如果用户选择不想要该图标则绕过此图标。
只有一个副作用,应用程序的菜单只有在失去焦点并重新获得焦点时才会显示。
来源:制作复选框以打开和关闭 Dock 图标
就我个人而言,我更喜欢不设置任何 Info.plist 选项,并根据具体情况使用
TransformProcessType(&psn, kProcessTransformToForegroundApplication)
或TransformProcessType(&psn, kProcessTransformToUIElementApplication)
是用户设置。To do it while abiding to the Apple guidelines of not modifying application bundles and to guarantee that Mac App Store apps/(Lion apps ?) will not have their signature broken by info.plist modification you can set LSUIElement to 1 by default then when the application launches do :
to show it's dock icon, or bypass this if the user chose not to want the icon.
There is but one side effect, the application's menu is not shown until it losses and regains focus.
Source: Making a Checkbox Toggle The Dock Icon On and Off
Personally i prefer not setting any Info.plist option and use
TransformProcessType(&psn, kProcessTransformToForegroundApplication)
orTransformProcessType(&psn, kProcessTransformToUIElementApplication)
based on what is the user setting.在 Xcode 中,它显示为“应用程序是代理(UIElement)”并且它是布尔值。
在 Info.plist 控件中单击空白区域,然后从菜单中选择“添加行”
类型“应用程序是代理(UIElement)”
将其设置为“是”。
为了使其可选,我将以下行添加到我的代码中(感谢 Valexa!)
In Xcode it is shown as "Application is agent (UIElement)" and it is Boolean.
In your Info.plist control-click to an empty space and select "Add Row" from the menu
Type "Application is agent (UIElement)"
Set it YES.
TO make it optional I added the following line to my code (thanks Valexa!)
Swift 更新:(使用上面介绍的两种方法,它们具有相同的结果)
Update for Swift: (Use both ways has been presented above, they have the same result)
尝试不同的变体后,我仍然遇到如下所示的问题:
NSApplication.ActivationPolicy.regular)。 您需要首先切换到其他应用程序(例如Finder.app),然后切换回您的应用程序以使应用程序菜单按预期工作。
NSApplication.ActivationPolicy.accessory
后),应用程序窗口向后/隐藏。 您需要启动“任务控制”才能显示应用程序窗口。为了解决上述问题,我做了一个扩展:
用法:
前提条件:
Info.plist
设置LSUIElement
不存在或设置为值NO
。After trying different variants I still had issues shown below:
NSApplication.ActivationPolicy.regular
). You need first switch to some other app (e.g. Finder.app) and then switch back to your app to make App menu working as expected.NSApplication.ActivationPolicy.accessory
). You need to launch "Mission control" to reveal App windows.To solve above issues I made an extension:
Usage:
Precondition: The
Info.plist
settingLSUIElement
is not present or set to valueNO
.如果你想让它成为用户首选项,那么你不能使用 UIElement。 UIElement 驻留在应用程序包中,您不应编辑应用程序包中的任何文件,因为这将使包签名无效。
我找到的最佳解决方案基于 这篇优秀的文章。 我的解决方案基于 Dan 的评论。 简而言之,用 Cocoa 无法做到这一点,但用一点点 Carbon 代码就可以做到。
该文章还建议制作一个专门处理停靠栏图标的帮助应用程序。 然后主应用程序根据用户的偏好启动并终止该应用程序。 这种方法让我觉得比使用 Carbon 代码更健壮,但我还没有尝试过。
If you want to make it a user preference then you can't use UIElement. UIElement resides in the application bundle you shouldn't edit any of the files in the app bundle as this will invalidate the bundles signature.
The best solution I've found is based on this excellent article . My solution is based on the comment by Dan. In short, There's no way to do this with Cocoa, but it is possible with a tiny bit of Carbon code.
The article also suggests making a helper app that handles the dock icon exclusively. The main app then starts and kills this app depending on the users preferences. This approach strikes me as being more robust than using the Carbon code, but I haven't tried it yet.