在 MacOS 上最小化到托盘
Minimize to tray on MacOSX
早上好,在我的 MacOSX 应用程序中,我想为用户提供选项 "minimize to tray"。我用的是Qt5,我重写了
changeEvent(QEvent *event)
函数。在那里我做了类似
的事情
switch( event->type() )
{
case QEvent::WindowStateChange:
{
if ( this->windowState() & Qt::WindowMinimized ) {
if( *option minimize to tray enable* ) {
event->ignore();
QTimer::singleShot(0, this, SLOT(hide()));
}
}
break;
}
default:
break;
}
嗯,它适用于 Linux 和 Windows,但问题是在 MacOSX 中此代码无法正常工作并产生错误。实际上 window 仍然在任务栏中最小化(除了停靠栏),而且,如果 window 从任务栏而不是托盘图标调整大小,GUI 将被阻止并且不会更改。 GUI 仍然可以发送信号,但不能更改。我必须重新显示托盘图标中的 window 才能解锁 GUI。
然后问题:如何避免在 MacOSX 上最小化任务栏中的 Window?
另一个相关问题:我读过一些论坛,其中一些用户谈到了 MacOSX 中的 "standard behaviour",例如单击 "x" 按钮时不关闭应用程序,或者不关闭应用程序使用托盘图标 ecc。 ecc.... 有人可以 post 官方 link 应用程序在 MacOSX 中应该如何表现?
非常感谢大家
嗯,我不了解 Qt,但我很了解 Cocoa。就 Objective-C API 而言,您的 hide()
调用可能相当于 -orderOut:
。不幸的是,-orderOut:
对于最小化的 windows 无法正常工作。它在 Dock 中留下一个 "ghost" window,可以将其最小化为实际的幽灵 window。也就是说,它只是 window 的图像,而不是实际的直播 window。
调用-close
确实有效。我不知道 Qt 的等价物是什么。但是,您必须小心避免 -close
超出 -orderOut:
的一些次要后果。例如,某些 windows 设置为在关闭时自行释放,您希望将其禁用。此外,window 委托的 -windowWillClose:
方法将被调用,它不应该为非真正关闭的调用做任何事情。
不用担心 "closing" 比 "hiding" 或 "ordering out" 更严重或更持久。除了上面提到的额外后果之外,这实际上是一回事。例如,仍然可以重新显示已关闭的window等
问题是,Qt 是否为您提供了执行此操作的灵活性。或者,这可以被认为是 Qt 中的一个错误,它的 hide()
实现在最小化 windows.
上使用 -orderOut:
而不是 -close
最后,我会问你是否真的想实现这个功能。这会让用户感到困惑。当您最小化 window 时,它会将最小化动画化到 Dock。这给用户留下了在哪里可以找到 window 的强烈印象。如果 window 随后没有在它去的地方找到,用户将不会知道去别处寻找。同样,Exposé/Mission Control 向用户显示应用程序的最小化 windows 除了正常 windows。你应该最小化到托盘 windows 不会出现在那里,因为它们不再真正最小化。
也许只是禁用最小化。让用户在完成后简单地关闭 window,然后从您的状态项菜单中重新打开它。
早上好,在我的 MacOSX 应用程序中,我想为用户提供选项 "minimize to tray"。我用的是Qt5,我重写了
changeEvent(QEvent *event)
函数。在那里我做了类似
的事情switch( event->type() )
{
case QEvent::WindowStateChange:
{
if ( this->windowState() & Qt::WindowMinimized ) {
if( *option minimize to tray enable* ) {
event->ignore();
QTimer::singleShot(0, this, SLOT(hide()));
}
}
break;
}
default:
break;
}
嗯,它适用于 Linux 和 Windows,但问题是在 MacOSX 中此代码无法正常工作并产生错误。实际上 window 仍然在任务栏中最小化(除了停靠栏),而且,如果 window 从任务栏而不是托盘图标调整大小,GUI 将被阻止并且不会更改。 GUI 仍然可以发送信号,但不能更改。我必须重新显示托盘图标中的 window 才能解锁 GUI。
然后问题:如何避免在 MacOSX 上最小化任务栏中的 Window?
另一个相关问题:我读过一些论坛,其中一些用户谈到了 MacOSX 中的 "standard behaviour",例如单击 "x" 按钮时不关闭应用程序,或者不关闭应用程序使用托盘图标 ecc。 ecc.... 有人可以 post 官方 link 应用程序在 MacOSX 中应该如何表现?
非常感谢大家
嗯,我不了解 Qt,但我很了解 Cocoa。就 Objective-C API 而言,您的 hide()
调用可能相当于 -orderOut:
。不幸的是,-orderOut:
对于最小化的 windows 无法正常工作。它在 Dock 中留下一个 "ghost" window,可以将其最小化为实际的幽灵 window。也就是说,它只是 window 的图像,而不是实际的直播 window。
调用-close
确实有效。我不知道 Qt 的等价物是什么。但是,您必须小心避免 -close
超出 -orderOut:
的一些次要后果。例如,某些 windows 设置为在关闭时自行释放,您希望将其禁用。此外,window 委托的 -windowWillClose:
方法将被调用,它不应该为非真正关闭的调用做任何事情。
不用担心 "closing" 比 "hiding" 或 "ordering out" 更严重或更持久。除了上面提到的额外后果之外,这实际上是一回事。例如,仍然可以重新显示已关闭的window等
问题是,Qt 是否为您提供了执行此操作的灵活性。或者,这可以被认为是 Qt 中的一个错误,它的 hide()
实现在最小化 windows.
-orderOut:
而不是 -close
最后,我会问你是否真的想实现这个功能。这会让用户感到困惑。当您最小化 window 时,它会将最小化动画化到 Dock。这给用户留下了在哪里可以找到 window 的强烈印象。如果 window 随后没有在它去的地方找到,用户将不会知道去别处寻找。同样,Exposé/Mission Control 向用户显示应用程序的最小化 windows 除了正常 windows。你应该最小化到托盘 windows 不会出现在那里,因为它们不再真正最小化。
也许只是禁用最小化。让用户在完成后简单地关闭 window,然后从您的状态项菜单中重新打开它。