After installing plasma 5.11 the launchInPlace from TasksModel from libtaskmanager which is supposed to put the windows in the same place that the launchers are is not working... The launcher is removed and its windows are put at the end of the list This is observed on both the plasma icon-only taskmanager and also Latte,
I can confirm this bug in Plasma 5.11 (KDE neon User Edition)
I can confirm, I observe the same behavior since the latest upgrade today to plasma 5.11 (Arch Linux)
Also reported in bug 385563.
*** Bug 385563 has been marked as a duplicate of this bug. ***
*** Bug 385618 has been marked as a duplicate of this bug. ***
*** Bug 385619 has been marked as a duplicate of this bug. ***
I played a bit with the icon-only plasma taskmanager by enforcing separateLaunchers:false the experience was very broken when the user was pinning launchers in different activities and windows in specific activities. The launchers were changing positions without predictability and there was a case in an activity that I ended up with two different kwrite launchers (one in the beginning and one at the end) without having a kwrite window in that activity...
These two functions from TasksModel are also broken, what is happening is the following. Plasma possibly added new functionality in 5.11 for which a task's launcher url is changed in something more generic. For systemsettings that would be, applications:systemsettings.desktop . I found that this is happening for launchers and windows in 5.11, I dont know for startups. Because of this launcherPosition and launcherActivities return -1 and null accordingly. For cases that instead of the above the desktop url is used e.g. file:///usr/share/applications/systemsettings.desktop then the functions I think they worked correctly. I used the following code on the click event of a task in Latte in order to check the behavior. console.log("POS :::: "+ tasksModel.launcherPosition(LauncherUrlWithoutIcon) + " - " + tasksModel.launcherPosition(LauncherUrl) + " - " + tasksModel.launcherActivities(LauncherUrl)); at all cases of launchers and windows the results where "POS :::: -1 - -1 -"
I forgot to mention the functions that I think they are broken from TasksModel because I copy pasted from another issue. The functions in question are: launcherPosition, launcherActivities
Great investigation, Michail! Maybe this was introduced by https://cgit.kde.org/plasma-desktop.git/commit/?id=b293137ed955e076d72f47c86ea1a8539632bf5a ?
(In reply to Nate Graham from comment #10) > Great investigation, Michail! Maybe this was introduced by > https://cgit.kde.org/plasma-desktop.git/commit/ > ?id=b293137ed955e076d72f47c86ea1a8539632bf5a > > ? maybe... Only the developer can answer this. One more important thing I observed is that old launchers are in style: file:///usr/share/applications/systemsettings.desktop but all the new pinned launchers are in the form: applications:systemsettings.desktop I dont know what is the developer's intended behavior.. The first one or the latter one ? If it is the latter then there should be and update mechanism between plasma 5.10 and 5.11 or the user should be informed that must readd all its launchers from scratch. If it is the first one then this is very important because 5.11.0 damages launchers data.
Looks like the second style ("Applications:something.desktop") is indeed expected now, and was introduced in https://phabricator.kde.org/D7561 and https://phabricator.kde.org/D7562 I guess it caused some unexpected fallout.
> I dont know what is the developer's intended behavior.. The first one or the latter one ? The new applications: type URL is so we can handle when a system-wide desktop file (in /usr/share) gets overriden by a user-local one in ~/.local/share. From what I can tell it *should* treat both the same but the rewriting or mapping between the absolute path and applications path causes trouble here?
Design-wise, is that actually a desirable goal? Let's say I have a desktop file for a program in /usr/local/share/ and I pin a Task Manager entry for it. All is well. Now for whatever reason I create a .desktop file for it in ~/.local/share/, and perhaps that .desktop file is slightly different. My expectation is that the Task Manager icon still opens the original thing I told it to open, and that if I wanted a Task Manager icon open the one in ~/.local/share, I would make one myself. Having it open the one in ~/.local/share without warning strikes me as something that could cause surprise. Regardless, this is quite a niche corner case; how many people even have .desktop files in ~/.local/share that would otherwise conflict with the ones in /usr/local/share?
> Design-wise, is that actually a desirable goal? Yes it is. This is the way desktop files are supposed to work and work everywhere else. (Except for the icon plasmoid because that's a whole other story) Anyway, from what I can tell is that the startup task matches to /usr/share/applications/org.kde.dolphin.desktop whereas the running application ends up being mapped to applications:org.kde.dolphin.desktop Eike is at Qt World Summit right now, I'll try to have a look as to why that happens. > Regardless, this is quite a niche corner case; how many people even have .desktop files in ~/.local/share that would otherwise conflict with the ones in /usr/local/share? Apps can do that, cf. dynamic jump list actions in Kate, users can also edit applications to their liking, etc.
*** Bug 385631 has been marked as a duplicate of this bug. ***
(In reply to Kai Uwe Broulik from comment #15) > > Anyway, from what I can tell is that the startup task matches to > /usr/share/applications/org.kde.dolphin.desktop whereas the running > application ends up being mapped to applications:org.kde.dolphin.desktop > how about the launcherPosition and launcherActivities functions from TasksModel shouldnt these functions also understand the new urls e.g. applications:systemsettings.desktop in order to not return -1 and null when the new style is used?
Please give a try to https://phabricator.kde.org/D8257 and more importantly https://phabricator.kde.org/D8258
(In reply to Kai Uwe Broulik from comment #18) > Please give a try to > https://phabricator.kde.org/D8257 > and more importantly > https://phabricator.kde.org/D8258 Kai unfortunately I am in a new machine because my old one broke and I havent found time to build Plasma yet from master
(In reply to Kai Uwe Broulik from comment #18) > Please give a try to > https://phabricator.kde.org/D8257 > and more importantly > https://phabricator.kde.org/D8258 I rebuilt the archlinux package (I'm on manjaro) using the 2 patch above and all the icons on my icon only task manager works like as before. they are not jumping around anymore. I use only 1 desktop and 1 activity I can't test other weird comportment that was seen by Michail Vourlakos. if some other test is needed.
*** Bug 385689 has been marked as a duplicate of this bug. ***
(In reply to Kai Uwe Broulik from comment #18) > Please give a try to > https://phabricator.kde.org/D8257 > and more importantly > https://phabricator.kde.org/D8258 After recompiling libtaskmanager patched with D8257 and D8258 everything seem's to work fine (arch).
*** Bug 384703 has been marked as a duplicate of this bug. ***
(In reply to Kai Uwe Broulik from comment #18) > Please give a try to > https://phabricator.kde.org/D8257 > and more importantly > https://phabricator.kde.org/D8258 Kai hello, I managed to build plasma and test the patches... The patches fix this issue both for plasma taskmanagers and Latte and launchInPlace works now both for file:///... launchers and application:.. one I found two more issues though (I can open different threads when the mentioned patches land): A - 1. add a launcher in a taskmanager through krunner 2. try to set Activities for this launcher when its window is open, the Activities can not be altered properly in that case B - this one is discovered through Latte so I dont know if plasma wants to take into account the case: 1. add a launcher by pinning through the context menu when its window is open 2. set that launcher explicit in an activity 3. move to that activity 4. change to another activity. Latte shows that this launcher when is removed (because it doesnt belong to the new activity) it is moved first to position 0. This wasnt observed in 5.11.0 and even now in plasma taskmanagers isnt noticed by the user I think but in Latte because there is an animation for the removal catches the eye
forget the (B) issue, after a relogin it was fixed by its own...
How do you add a launcher through KRunner? drag and drop? If so, also try https://phabricator.kde.org/D8260
(In reply to Kai Uwe Broulik from comment #26) > How do you add a launcher through KRunner? drag and drop? If so, also try > https://phabricator.kde.org/D8260 yes, through drag n' drop I can confirm that patch fixes the issue with assigning activities. One more issue from icon-only taskmanager: 1.the user adds a launcher through drag n' drop 2.the launcher is added 3.the user tries to set its activities and can not because context menu offers only Unpin. The only way to set Activities for a launcher that doesnt have a window shown is by showing its window and try again its context menu.
Git commit 5fee12f8bee6491cb03a4fa04509c96e04ccfb77 by Kai Uwe Broulik. Committed on 16/10/2017 at 08:44. Pushed by broulik into branch 'Plasma/5.11'. [LauncherTasksModel] Try resolving absolute path to applications: URL before adding launcher This way when a third party like pinning or dragging from Kickoff sends an absolute desktop file path we would still only store the application id if possible. Differential Revision: https://phabricator.kde.org/D8260 M +16 -0 libtaskmanager/launchertasksmodel.cpp https://commits.kde.org/plasma-workspace/5fee12f8bee6491cb03a4fa04509c96e04ccfb77
Git commit 88dbb40ddedee4740b904e9a6f57beda80013550 by Kai Uwe Broulik. Committed on 16/10/2017 at 08:43. Pushed by broulik into branch 'Plasma/5.11'. [Task Tools] Treat applications: and respective absolute path equal in launcherUrlsMatch CHANGELOG: Fixed issue that caused pinned applications in task manager to erroneously shift around FIXED-IN: 5.11.1 Differential Revision: https://phabricator.kde.org/D8258 M +31 -2 libtaskmanager/tasktools.cpp https://commits.kde.org/plasma-workspace/88dbb40ddedee4740b904e9a6f57beda80013550
*** Bug 385799 has been marked as a duplicate of this bug. ***
I can confirm that in the Plasma 5.11.1 it has acceptable behavior. Although I very appreciate this quick fix - Thank you! - it has a little bit different visual response. The icon first show in the most right side and then when the application starts, the icon quickly moves to expected location. The previous behavior did not showed the icon temporarily on the right.
Can you open a new ticket to track that visual regression, and link it to this one?
It seems that restart helped. I shared the observation of the bugfix behavior on system which was not restarted. When I did put two systems (old ok, new with fix) side by side freshly booted, it worked like a charm. So there is no need to open the visual visual regression issue bug.
Glad to hear it!
Created attachment 108586 [details] Screenshot This is still happening with the icon for Libre Office, as shown in the attached screenshot. Top: LO Icon position before opening application. Bottom: LO Icon moves to far right when application is open. Plasma: 5.11.1 Frameworks: 5.38.0 Qt: 5.9.2
(In reply to Paul from comment #35) > Created attachment 108586 [details] > Screenshot > > This is still happening with the icon for Libre Office, as shown in the > attached screenshot. > > Top: LO Icon position before opening application. > Bottom: LO Icon moves to far right when application is open. > > Plasma: 5.11.1 > Frameworks: 5.38.0 > Qt: 5.9.2 Same here. Work around, unpin libre office, start it from application menu, once application is running right click it on taskbar in select pin.
Re-opening since it seems that this is not entirely fixed yet.
(In reply to Nikolay Zlatev from comment #36) > Same here. Work around, unpin libre office, start it from application menu, > once application is running right click it on taskbar in select pin. Strange... That hasn't "solved" the problem on this setup. With LO closed, unpin the icon. Start LO from Application menu. When started pin icon. (Now at far right) Close LO. Reposition Icon to desired place in the taskbar. Start LO fron Taskbar Icon, whilst LO is in the process of opening there are two icons, one at the original position, one far right. Once LO is open the far right icon remains. Close LO and the icon reverts to it's original position.
Created attachment 108606 [details] Screenshot showing icon returned to correct position upon opening Application Menu. A further observation: If, whilst LO is open and the icon has moved to the far right, the Application Menu (or a plasmoid, for example Network Manager or the Digital Clock) is opened, then the LO icon returns to it's correct original position. (If LO is closed and reopened then again the icon moves far right.)
Is anybody who's experienced this still able to reproduce it in 5.11.4? I was able to earlier but can't anymore as of Plasma 5.11.4.
*** Bug 386056 has been marked as a duplicate of this bug. ***
Created attachment 109373 [details] Screenshot showing two LO icons Still happening with Libre Office. See attached screenshot. Unpinning and re-pinning icons does not solve the issue. Plasma 5.11.4 Frameworks 5.40.0 Qt 5.9.3
Can you reproduce the issue with an app that doesn't have spaces in the name? If not, then the remaining issue may be https://bugs.kde.org/show_bug.cgi?id=385942
(In reply to Nate Graham from comment #43) > Can you reproduce the issue with an app that doesn't have spaces in the > name? If not, then the remaining issue may be > https://bugs.kde.org/show_bug.cgi?id=385942 For me this bug is already fixed. Also Libreoffice from Ubuntu 16.04 works ok. However as I am still receiving notifications, I noticed this suggestion that the libreoffice issue can be caused by space in the name. Quickly I did the test and it looks that space in the name cases this. I did test for LO and also for another app and both they suffered the behavior described here.
Created attachment 109376 [details] VLC Launcer (with spaces in name) is correctly placed Good catch, possibly... No I've not seen it with applications that have names sans spaces. But... I've added VLC as a pinned application, which has the name "VLC media player", the icon for that behaves correctly. (Screenshot attached). Did you mean the descriptive name, or the application name?
Application with space in the name can't be pinned at all. No error message, but if I choose "Add to Panel(Widget)" from menu, application attach to panel but system receive log message "14 16:31:04 plasmashell[10610]: Empty filename passed to function" _NET_WM_ICON_NAME(UTF8_STRING) = XdndAware(ATOM) = BITMAP WM_NAME(STRING) = "Data Extractor" _NET_WM_NAME(UTF8_STRING) = "Data Extractor" _KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 25882978 _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x3e, 0x7e, 0x0, 0x0 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL _XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x1 WM_CLIENT_LEADER(WINDOW): window id # 0x4e00007 WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. _NET_WM_PID(CARDINAL) = 25527 _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 81788934 WM_CLASS(STRING) = "DataExtractor", "DataExtractor" WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_NORMAL_HINTS(WM_SIZE_HINTS): user specified location: 4, 29 user specified size: 1272 by 687 program specified minimum size: 1010 by 640 window gravity: Static
(In reply to Nikolay Zlatev from comment #46) > Application with space in the name can't be pinned at all. > No error message, but if I choose "Add to Panel(Widget)" from menu, > application attach to panel but system receive log message "14 16:31:04 > plasmashell[10610]: Empty filename passed to function" > > > _NET_WM_ICON_NAME(UTF8_STRING) = > XdndAware(ATOM) = BITMAP > WM_NAME(STRING) = "Data Extractor" > _NET_WM_NAME(UTF8_STRING) = "Data Extractor" > _KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 25882978 > _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x3e, 0x7e, 0x0, 0x0 > _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL > _XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x1 > WM_CLIENT_LEADER(WINDOW): window id # 0x4e00007 > WM_HINTS(WM_HINTS): > Client accepts input or input focus: True > Initial state is Normal State. > _NET_WM_PID(CARDINAL) = 25527 > _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 81788934 > WM_CLASS(STRING) = "DataExtractor", "DataExtractor" > WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, > _NET_WM_PING, _NET_WM_SYNC_REQUEST > WM_NORMAL_HINTS(WM_SIZE_HINTS): > user specified location: 4, 29 > user specified size: 1272 by 687 > program specified minimum size: 1010 by 640 > window gravity: Static On App start дек 14 16:39:27 telamon kactivitymanagerd[10633]: Creating the cache for: "applications:Data Extractor.desktop" дек 14 16:39:27 telamon kactivitymanagerd[10633]: Already in database? true дек 14 16:39:27 telamon kactivitymanagerd[10633]: First update : QDateTime(2017-06-23 19:17:50.000 EEST Qt::TimeSpec(LocalTime)) дек 14 16:39:27 telamon kactivitymanagerd[10633]: Last update : QDateTime(2017-12-14 16:39:06.000 EET Qt::TimeSpec(LocalTime)) дек 14 16:39:27 telamon kactivitymanagerd[10633]: After the adjustment дек 14 16:39:27 telamon kactivitymanagerd[10633]: Current score : 16.7956 дек 14 16:39:27 telamon kactivitymanagerd[10633]: First update : QDateTime(2017-06-23 19:17:50.000 EEST Qt::TimeSpec(LocalTime)) дек 14 16:39:27 telamon kactivitymanagerd[10633]: Last update : QDateTime(2017-12-14 16:39:06.000 EET Qt::TimeSpec(LocalTime)) дек 14 16:39:27 telamon kactivitymanagerd[10633]: Interval length is 0 дек 14 16:39:27 telamon kactivitymanagerd[10633]: New score : 17.7956 дек 14 16:39:27 telamon kactivitymanagerd[10633]: ResourceScoreUpdated: "c4440aa5-23a1-46d9-9837-305110763943" "org.kde.plasma.kicker" "applications:Data Extractor.desktop" дек 14 16:39:27 telamon plasmashell[10610]: KActivitiesStats( 0x55d230a0fe50 ) ResultModelPrivate::onResultScoreUpdated result added: "applications:Data Extractor.desktop" score: 17.7956 last: 1513262365 first: 1498234670
Thanks for the tests, everyone. let's close this since the original issue is now fixed, and track the remaining issue that concerns app URLs with spaces in them using Bug 385942.
So for anyone continuing to investigate (thanks!) please put your comments in Bug 385942 instead of here.