Windows, macOS, KDE4 and most versions of KDE5 had the correct behavior, but the latest versions of plasma5 have this bug, it started recently. #include <QApplication> #include <QWidget> #include <QtWidgets> int main(int argc, char **argv) { QApplication app(argc, argv); QWidget w; w.setWindowFlags(w.windowFlags() | Qt::Tool); w.show(); return app.exec(); } Reproducible: Always
What NETWM window type does Qt::Tool correspond to? What's a real-world app use case I could test?
According to [1] Qt::Tool corresponds to _NET_WM_WINDOW_TYPE_UTILITY [1] https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/xcb/qxcbwindow.cpp#n1865
We hide _NET_WM_WINDOW_TYPE_TOOL but do show _NET_WM_WINDOW_TYPE_UTILITY. This should have been the same in Plasma 4 and previous versions of Plasma 5, actually. I'd need some real world app examples to see whether that makes sense or not. Until then we'd err on the side of showing more rather than fewer windows.
Ah nevermind, I had a closer look at the old libtaskmanager code, and while this, on line 264, doesn ot discard utility windows: https://quickgit.kde.org/?p=plasma-workspace.git&a=blob&h=bbd496d77f5ca9856e289a6cd9daa1c675aca68a&hb=26c3fe19e3502d2e2cdd718865fdec996b853a2c&f=libtaskmanager%2Ftaskmanager.cpp This, on line 348, does: https://quickgit.kde.org/?p=plasma-workspace.git&a=blob&h=fb7cdc9a4dbed7e5bf32a3fbbd432274da02d189&hb=26c3fe19e3502d2e2cdd718865fdec996b853a2c&f=libtaskmanager%2Fgroupmanager.cpp Bleh. Spaghetti codebase.
Git commit 7dee461947ae2fa6666cf7a6d0234fc92cabcc66 by Eike Hein. Committed on 19/09/2016 at 07:51. Pushed by hein into branch 'Plasma/5.8'. Treat NET::Utility type windows as SkipTaskbar. Summary: Utility windows (NET::Utility/_NET_WM_WINDOW_TYPE_UTILITY) should not be on the Task Manager, but they should be on the Pager. This patch achieves this by evaluating the window type in the AbstractTasksModel::SkipTaskBar data role. I considered the alternative approach of making a new AbstractTasksModel::IsUtilityWindow (or similar) data role and adding a pass to evaluate it to TaskFilterProxyModel, then configuring the filter models in TasksModel and the Pager backend differently. But this is not very extensible. Then I realized that AbstractTasksModel data roles do not and should not reflect X11 idioms anyway; the point of the library is to abstract for the purpose of UI, and what XWindowTasksModel considers "SkipTaskBar" is really an implementation detail. This makes all the more sense considering on Wayland we have no notion of window types (beyond "popup") yet, and don't quite now how it's going to evolve. Various API docstrings have been changed to better reflect that the meaning of the data role doesn't map to anything specific in the tasks. Reviewers: #plasma, davidedmundson, broulik Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D2807 M +2 -2 libtaskmanager/abstracttasksmodel.h M +16 -16 libtaskmanager/taskfilterproxymodel.h M +9 -1 libtaskmanager/xwindowtasksmodel.cpp http://commits.kde.org/plasma-workspace/7dee461947ae2fa6666cf7a6d0234fc92cabcc66