Always group tasks, even when new task demands attention.
Details
- Reviewers
hein - Group Reviewers
Plasma - Commits
- R119:b6a4964c5f21: TaskManager: Force grouping for Icons-Only Task Manager
When a demand attention task is ungrouped, it won't be grouped
back when it loses the demand attention state (bug?). On my system, sometimes
when I open konsole/dolphin with global shortcut, the window will get opened
as inactive (under other windows) and will get demand attention state. That way,
I have now multiple icons for the same program in taskmanager.
I think it doesn't make sense to ungroup those tasks in icons-only mode, even
if the behavior described above is changed/fixed.
Diff Detail
- Repository
- R119 Plasma Desktop
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Please, revert this, or find another workaround, because I miss this feature! I loved being able to ungroup my apps in the icons-only task manager. Without it, it is far less easy to work on multiple different projects in the Atom text editor as I used different windows for different projects.
Sorry, this also disabled manual ungrouping, that wasn't intended.
Eike: Ideally, the fix would be just to disable the ungrouping for demand attention tasks or fixing the behavior so the task will get grouped back after it loses the demand attention state. What do you think?
My personal preference is the original. That's why I created this PKGBUILD for plasma-desktop on Arch Linux (my current platform) :
bash # $Id: PKGBUILD 263281 2016-03-29 16:18:46Z arojas $ # Maintainer: Felix Yan <felixonmars@archlinux.org> # Maintainer: Antonio Rojas <arojas@archlinux.org> # Contributor: Andrea Scarpino <andrea@archlinux.org> pkgname=plasma-desktop pkgver=5.6.1 pkgrel=1 pkgdesc='KDE Plasma Desktop' arch=('i686' 'x86_64') url='https://www.kde.org/workspaces/plasmadesktop/' license=('LGPL') source=("http://download.kde.org/stable/plasma/$pkgver/$pkgname-$pkgver.tar.xz" "taskmanager.patch") depends=('powerdevil' 'polkit-kde-agent' 'libcanberra' 'libxkbfile' 'kmenuedit' 'systemsettings' 'ksysguard' 'kpeople' 'baloo' 'qt5-graphicaleffects') makedepends=('extra-cmake-modules' 'kdoctools' 'boost' 'xf86-input-evdev' 'xf86-input-synaptics' 'xorg-server-devel' 'libibus' 'scim') optdepends=('plasma-nm: Network manager applet' 'ibus: kimpanel IBUS support' 'scim: kimpanel SCIM support') conflicts=('kdebase-workspace' 'kcm-touchpad-frameworks' 'kdeplasma-addons<5.5.95' 'kactivities<5.19.0-3') replaces=('kcm-touchpad-frameworks') install=$pkgname.install groups=('plasma') md5sums=('4ef14da95b219c50e3ea5cf032f38ec6' '918f1f2292ef3732f523f3d9caa8fa91') prepare() { mkdir -p build patch -p1 ${pkgname}-${pkgver}/applets/taskmanager/package/contents/ui/main.qml < taskmanager.patch } build() { cd build cmake ../$pkgname-$pkgver \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=/usr \ -DLIB_INSTALL_DIR=lib \ -DLIBEXEC_INSTALL_DIR=lib \ -DKDE_INSTALL_USE_QT_SYS_PATHS=ON \ -DBUILD_TESTING=OFF make } package() { cd build make DESTDIR="$pkgdir" install }
where taskmanager.patch is:
patch From f60f8934eff1b91720c0ff809be4153f953f1083 Mon Sep 17 00:00:00 2001 From: Brenton Horne <brentonhorne77@gmail.com> Date: Wed, 30 Mar 2016 18:40:44 +1000 Subject: [PATCH] Update main.qml --- applets/taskmanager/package/contents/ui/main.qml | 6 ------ 1 file changed, 6 deletions(-) diff --git a/applets/taskmanager/package/contents/ui/main.qml b/applets/taskmanager/package/contents/ui/main.qml index 1094532..230d52a 100644 --- a/applets/taskmanager/package/contents/ui/main.qml +++ b/applets/taskmanager/package/contents/ui/main.qml @@ -185,12 +185,6 @@ Item { value: !iconsOnly } - Binding { - target: backend.groupManager - property: "forceGrouping" - value: iconsOnly - } - TaskManager.DragHelper { id: dragHelper
Ideally, the fix would be just to disable the ungrouping for demand attention tasks or fixing the behavior so the task will get grouped back after it loses the demand attention state. What do you think?
I'd prefer to fix it properly. I decided to give a greenlight to the workaround mostly because the code is slated to be replaced, but given the user demand it seems sensible to address it in the 5.6.x branch after all.