In icons-only task manager, my chromium launcher has "show a launcher when not running" enabled. However, most of the time when I disable chromium it disappears from the task manager completely. When I start it again, it shows up properly and still with "show a launcher..." enabled. This sometimes happen with other apps, but mostly with chromium. Also, launchers sometimes "shuffle" randomly when I open new apps. This started to happen after the 5.7.0 upgrade. What's more, when I disable "show a launcher..." in any of my launchers, they dont move to the end of the list as they used to. It seems that the task manager doesn't recognize that I even changed anything. The same is for the opposite: when I open a new program and click "show a launcher..." it doesn't move to the left and doesn't "push" the not-launchers to the right as it used to. Reproducible: Sometimes Steps to Reproduce: 1. Pin some applications to your Icons-only task bar (you may need to pin chromium, but I am not sure) 2. Have it open for some time, browse net. 3. Exit chromium. Your pinned launcher (with "show a launcher" option enabled) will disappear Actual Results: Chromium icon disappeared Expected Results: Chromium icon should have stayed in place after closing the app.
Do you still have 5.7.0 or actually 5.7.1? Do you have more than one Task Manager?
Git commit a1378f8591691ecf32ab4b87349d2037ae9c569a by Eike Hein. Committed on 13/07/2016 at 16:42. Pushed by hein into branch 'Plasma/5.7'. Fix managing separateLaunchers prop for Icontasks. M +8 -2 applets/taskmanager/package/contents/ui/main.qml http://commits.kde.org/plasma-desktop/a1378f8591691ecf32ab4b87349d2037ae9c569a
Git commit c3941de089b886d4fbfcc99bfec0bc62e03db894 by Eike Hein. Committed on 13/07/2016 at 16:45. Pushed by hein into branch 'Plasma/5.7'. Fix edge case with launchInPlace + SortManual + group. Bonus: Speed up by using the WithoutIcon data role in lessThan. M +8 -6 libtaskmanager/tasksmodel.cpp http://commits.kde.org/plasma-workspace/c3941de089b886d4fbfcc99bfec0bc62e03db894
Git commit 3e0c3f4db409d11361162f249ae5006e4a57a324 by Eike Hein. Committed on 13/07/2016 at 17:00. Pushed by hein into branch 'Plasma/5.7'. Move formerly launcher-backed window tasks out of launcher area on launcher removal. M +14 -4 libtaskmanager/tasksmodel.cpp http://commits.kde.org/plasma-workspace/3e0c3f4db409d11361162f249ae5006e4a57a324
The disappearing was probably solved by e2b07027de7c. Please reopen if these problems persist with 5.7.2 (or after updating to the current 5.7 branch, if you have access to git builds).
ADDITIONAL INFO: I use only one task manager (icons only) and yes, I have actually the 5.7.1 version. Thank you. I'll probably wait until 19.07 and 5.7.2 release, for Arch it should be available on the same day.
Unfortunately, it was not completely fixed in 5.7.2. I reopen this report. What was fixed: - now when selecting "show icon..." moves the launchers to the left, and non-launchers to the right as is used to What was not fixed: - disappearing of icons. I open chrome, select "show icon...", then I close it and it disappears. The same is for example with libre office launcher. I open it, enable "show launcher...", then I choose for example new calc, close it and the libre icon which should be pinned to the task manager disappears. When I change a something in a .desktop file of the lost launcher it shows up again, until I open it and close, then it disappears once again. It is strange because for example icons for dolphin, cantata, octave never were affected by this bug.
Both Chrome and LibreOffice use window ids that make it difficult to map them to launchers. Perhaps something isn't right with your taskmanagerrulesrc (a mapping table we ship to work around this)
Can you give us some additional data like your appletsrc launcher URL for Chromium and the location of its .desktop file on your system?
I am using chromium.desktop in root directory: /usr/share/applications/ but the same problem was when I moved it to ~/.local/share/applications just for testing. In a moment I will attach my appletsrc, taskmanagerrulesrc and chromium.desktop files.
Created attachment 100190 [details] taskmanagerrulesrc
Created attachment 100191 [details] appletsrc
Created attachment 100192 [details] chromium.desktop
Can you further attach xprop output for the Chromium window?
Created attachment 100230 [details] xprop output Attaching xprop output
Hmm, tricky, all the data looks good ... WM_CLASS matches name of the .desktop file, launcher URL is good in appletsrc. This shouldn't be a metadata problem.
It's even stranger for me that it shows up after reboot, I don't have to do anything. One more thing that I noticed right now: after copying desktop file to my home local folder the launcher appears when I open my .local/share/applications folder in Dolphin. It appears only at that moment and when opening chrome it shows up as a second launcher (it doesn't merge with the former one, made from the desktop file in the root directory). Then, after closing it disappears again. In arch forums I noticed that someone had the same problem while testing 5.7.0 beta and at least one person on 5.7.1 (only one person admitted that on my thread).
I mean chromium, sorry, I make this mistake all the time.
It's not that weird or surprising - the code works roughly like this: 1) Whenever a new launcher appears or data for an existing launcher changes, the data model checks whether there are any windows for the same app, and if there are, the launcher is filtered out, otherwise it is shown 2) Whenever a window is closed, the data model checks whether there are any launchers for the same app, and if so, triggers a "the data for this launcher changed", so that (1) runs again, implicitly now revealing a previously filtered-out launcher 3) When the system binary cache of .desktop data changes (e.g. by touching a filesystem location with .desktop stuff), the launcher data model reloads (e.g. to update icons and titles), causing data change notifications, causing (1) In other words it's obvious that (2) fails, but that's really odd because (2) uses the same logic for "is this for the same app?" as (1), and (1) presumably works for you (Chromium window replaces launcher). But then the window is closed and the launcher is not re-revealed, i.e. (2) failed. There was a bug causing (2) to fail under complicated circumstances (involving two Task Managers and a particular instanciation order and state), but the fix for that is in 5.7.2. According to the data you provided the "is this the same app?" logic should also have no problem with the launcher or window. So for now: No idea why it fails.
(Not to mention obviously I can't reproduce it here ...)
More have confimed this bug already, me too. You can find examples here as well. https://forum.manjaro.org/t/stable-2016-07-19-snapshot-ready-to-be-moved-to-stable/6019/33
Does Manjaro have a livecd or some other convenient thing with latest packages I could test?
No, need for it. I figured it out. I removed all files in the /.local/share/applications folder, made a logoff, login and re-added the problematic icons. Now it is working OK.
Are you sure? Because I've done that three times already, remove all launchers, completely purged my local applications folder, reboot, and add them again. Still the same story for me.
Okay, time for some more weird stuff... I created a new user and this problem didn't persist from the beginning but started to happen later. What I discovered is that chromium launcher disappears only if I have 3 or more opened and modified (non blank) tabs. So, for example: I open chromium and have only one clean "new tab". I close it and the icon does not disappear. Then I open it again and create two more clean tabs and close it - it does not disappear. And then, I open it again, create three tabs, open some random pages on them and THEN when I close chromium my launcher disappears.
Check if WM_CLASS in xprop output changes.
I checked it, it stays totally the same. Please check this manjaro build: https://sourceforge.net/projects/manjarotest/files/16.08-dev/kde/minimal/manjaro-kde-minimal-16.08-dev-x86_64.iso/download I use arch but this test build on my virtualbox produces the same bug. Sometimes you need to open 2, sometimes 3 tabs and random pages in them.
*** Bug 366292 has been marked as a duplicate of this bug. ***
I have same behaviour with application called dbeaver. But only if use "exit", but when i use "forced exit", all is ok! Maybe it will help you!
(In reply to xkmalikx from comment #25) > What I discovered is that chromium launcher disappears only if I have 3 or > more opened and modified (non blank) tabs. i tried this an i can reproduce it every time... (with a little addition) 1) open chrome 2) open at least 3 nonblank tabs 3) switch to one of these tabs !important 4) close chrome ---> chrome launcher is gone 1) open chrome from the application launcher 2) close chrome ---> chrome launcher is back and btw. i managed to get GIMP launcher removed to.. but i don't know how :(
sorry forgot to add using plasma: 5.8.90 frameworks: 5.28.0 qt: 5.7.0
*** Bug 373809 has been marked as a duplicate of this bug. ***
*** Bug 373625 has been marked as a duplicate of this bug. ***
Patch under review: https://phabricator.kde.org/D3950
Git commit 09ab6cdfb9766ccf5a2631ca07d262af3ed6d1d5 by Eike Hein. Committed on 06/01/2017 at 13:45. Pushed by hein into branch 'master'. Fix "Pinned Chrome disappears when all Chrome windows are closed" Summary: It turns out that Chrome under certain conditions will change its window metadata as it quits, causing a race we sometimes lose, failing to reveal the associated launcher because we can no longer match it to the window at window closing time. Instead we are now forced to re-check all launchers after the window is gone. As a speed optimi- zation we only consider top-level windows (and startups) as being in a group implies matching siblings. In addition this refactoring eliminates a use of Qt::QueuedConnection that allowed for an unpredictable event loop spin inbetween things. Reviewers: davidedmundson Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D3950 M +31 -11 libtaskmanager/tasksmodel.cpp https://commits.kde.org/plasma-workspace/09ab6cdfb9766ccf5a2631ca07d262af3ed6d1d5
Git commit cf6d8ab0dff2a6ba29574636ccfbe23c7917c48f by Eike Hein. Committed on 06/01/2017 at 14:16. Pushed by hein into branch 'Plasma/5.8'. Fix "Pinned Chrome disappears when all Chrome windows are closed" Summary: It turns out that Chrome under certain conditions will change its window metadata as it quits, causing a race we sometimes lose, failing to reveal the associated launcher because we can no longer match it to the window at window closing time. Instead we are now forced to re-check all launchers after the window is gone. As a speed optimi- zation we only consider top-level windows (and startups) as being in a group implies matching siblings. In addition this refactoring eliminates a use of Qt::QueuedConnection that allowed for an unpredictable event loop spin inbetween things. Reviewers: davidedmundson Subscribers: plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D3950 M +31 -11 libtaskmanager/tasksmodel.cpp https://commits.kde.org/plasma-workspace/cf6d8ab0dff2a6ba29574636ccfbe23c7917c48f