Bug 391539 - Pinned icon changes after application closes
Summary: Pinned icon changes after application closes
Status: RESOLVED WORKSFORME
Alias: None
Product: plasmashell
Classification: Plasma
Component: Task Manager and Icons-Only Task Manager (show other bugs)
Version: 5.12.2
Platform: Other Linux
: NOR normal
Target Milestone: 1.0
Assignee: Eike Hein
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-07 20:18 UTC by evea
Modified: 2022-03-01 04:36 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description evea 2018-03-07 20:18:36 UTC
Hello, I have a *.desktop file which opens Firefox with a new instance and a different WM_CLASS, this is useful if you want to use specific sites as an "app".

The problem is when I close said app (firefox instance), the icon changes back to the default FF one.
As you can see here: https://giant.gfycat.com/PinkGivingHuia.webm

This only happens, if you set a manual icon path, if you use a system icon it works as expected.

*.desktop file:
  Icon changes to FF after closing windows:
```
Icon=/home/ever/Fixes/Hangouts-icon.png
layout.latte enty: applications:hangouts.desktop?iconData=XXX (XXX = long randome characters, maybe base64 icon? decoding did not work..)
```

  Icon works and stays as expected:
```
Icon=wechat (system icon)
layout.latte enty: applications:hangouts.desktop
```

So it seems to be connected to the "?iconData=" entry, what is it and where does it come from?

It also works if I drag the first *.desktop file directly into the application laucnher, but that is not the point. Why is this happening and how can we avoid this?

Thank you.
Comment 1 Eike Hein 2018-03-31 09:47:50 UTC
This fell through the cracks because it was reported against the wrong component, sorry.

I'm currently on holidays, will look into it after.
Comment 2 evea 2018-04-05 12:32:33 UTC
Thank you, sometimes it is really hard to find the correct category on the bugtracker.

Hit me up if you need any more infos, it should be easy to reproduce.
Comment 3 evea 2018-05-26 22:34:08 UTC
Did you get a chance to look into it?
Comment 4 Eike Hein 2018-05-27 10:52:19 UTC
Sorry, I forgot about it! I've pinned it to near the top of my list now and will have a look during next week, promise.
Comment 5 Eike Hein 2018-05-30 15:32:58 UTC
Could you paste your full .desktop file?
Comment 6 Eike Hein 2018-05-30 15:45:58 UTC
I took an initial look, and so far I can't reproduce a problem with Icon=/path/to/file in .desktop files. An application that gets correctly mapped to such a .desktop file takes the correct icon from the .desktop file both as a window task and as a pinned launcher task.

My best guess at what's going on: You have this .desktop file to start Firefox with a different WM_CLASS, but your .desktop file doesn't contain a StartupWMClass= key matching that WM_CLASS. Therefore the Firefox window isn't mapped to the right .desktop file. For some seperate reason, it's also not mapped to any other .desktop file, which means when pinning, the icon is taken from the window icon, and stored in base64 in the config file.

Note also that while you can start Firefox with a different WM_CLASS, if you already have a running instance it will reuse the WM_CLASS of the first window for other windows.

Let me know if these pointers help you resolve things somehow. If you still suspect a bug, feel free to reopen this ticket and we can look into it together.
Comment 7 evea 2018-05-31 03:02:49 UTC
This was the original bugtracker post which led to me opening this here, should have added it from the beginning:
https://github.com/peppermintos/ice/issues/16
Comment 8 Michał Dybczak 2018-06-03 11:02:44 UTC
For me it doesn't matter if icon is set by ice-ssb or manually from system (through properties of a file) so I actually also can't reproduce the problem.

However, the issue is different.

a) If StartupWMClass=Chromium or any browser name, this desktop file assigned icon is set for the said browser, so in effect, setting ice-ssb app, the new icon overwrite chosen browser.
I assume this doesn't happen in other DEs so the question is, is this a bug or a feature. If it's the latter, how it can be overcome?

b)If StartupWMClass= is set to something else (non browser), then the window uses default browser icon and is grouped with browser, which is undesired.
Again, not sure if it's a bug or a feature and if how can it be overcome?
Comment 9 Eike Hein 2018-06-03 16:10:22 UTC
I'm sorry, I don't know what ice-ssb is. The above bug report is also about Firefox, not Chromium. Are you sure you posted in the right ticket?

I have a hard time understanding your comment, but if what you write in (a) is true, it seems that you didn't start the browser with a special WM_CLASS. All the windows with WM_CLASS "x" will get mapped to the .desktop file with StartupWMClass=X, that's what's supposed to happen. It's also different from what this bug reporter is talking about.

For apps that can't be started with a custom WM_CLASS or are buggy in some way, we have the taskmanagerrulesrc file where various complicated regex-based rewrite rules can be put.
Comment 10 Michał Dybczak 2018-06-03 17:22:00 UTC
ice-ssb is an app that allows for creating separate browser wrapped apps, so for example instead using facebook in browser tab, you can create a facebook app using firefox, chrome or chromium. ice-ssb creates desktop file that opens that created tab.
This is basically peppermint-os feature but the ice-ssb app is available for everyone to use and as it happens, it doesn't work well in Plasma, but we're not sure if that's because of how some things in Plasma work or it may be a bug?

I thought you red the link above to the ice-ssb issue (on github) which triggered this bug report. However, this initial bug seems to be not reproducible on your or mine machine because it works completely different than on posted video.

Since there is much more to it and it's hard to explain when you're completely out of the topic, I don't think it's appropriate to dig deeper and change the original subject, so sorry about creating a confusion and let's forget about my comments.
Comment 11 Eike Hein 2018-06-03 17:28:53 UTC
Ok, cool.

Tell you what though: Feel free to open up a seperate ticket like ".desktop files generated by ice-ssb don't work well" and upload an example .desktop file and xprop output for a resulting window, then I'm happy to look into it.
Comment 12 Michał Dybczak 2018-06-03 19:32:05 UTC
Thanks Elke, maybe at some later time, because ice-ssb developer should be involved in it and at this moment he is occupied with the new peppermint release.
Comment 13 evea 2018-06-05 03:39:51 UTC
I will try to explain it again with the according informations, the same thing happens with chromium.

I use ice (https://github.com/peppermintos/ice), to create a firefox "app". It creates a new profile, downloads the icon, creates a *.desktop shortcut and launches the "app" as a new instance with said profile.


________
Scenario 1 - which works as expected. (choose any system Icon)

Desktop file:
[Desktop Entry]
Version=1.0
Name=Google
Comment=Google (Ice SSB)
Exec=ice-firefox https://www.google.com/
Terminal=false
X-MultipleArgs=false
Type=Application
Icon=planetkde
Categories=GTK;Network;
MimeType=text/html;text/xml;application/xhtml_xml;
StartupNotify=true
IceFirefox=www.google.com_
StartupWMClass=www.google.com_

xprop|grep WM_CLASS
WM_CLASS(STRING) = "Navigator", "www.google.com_"

Latte Dock Layout:
applications:google.desktop

Video:
https://gfycat.com/WearyShortDotterel
________

Scenario 2 - Icon changes to Firefox icon when windows is closed (Choose icon with path)

Desktop file (Only "Icon" changes):
[Desktop Entry]
Version=1.0
Name=Google
Comment=Google (Ice SSB)
Exec=ice-firefox https://www.google.com/
Terminal=false
X-MultipleArgs=false
Type=Application
Icon=/home/ever/.local/share/ice/google.ico
Categories=GTK;Network;
MimeType=text/html;text/xml;application/xhtml_xml;
StartupNotify=true
IceFirefox=www.google.com_
StartupWMClass=www.google.com_

xprop|grep WM_CLASS
WM_CLASS(STRING) = "Navigator", "www.google.com_"

Latte Dock Layout:
https://pastebin.com/UAgVRMJZ

Video: https://gfycat.com/FamousOrangeFreshwatereel
________


So the problem seem to lie with the Base64 which is added to the panel/dock. If I manually remove "iconData" altogether and restart the panel/dock it works as expected, taking the *.desktop file icon.

I hope this post makes the bug clearer.
Comment 14 Eike Hein 2018-06-07 01:57:24 UTC
Thanks, the detailed info should help. I'll have another try at reproducing this.
Comment 15 Eike Hein 2018-06-08 02:40:39 UTC
I installed ice now, from the git link you put above, but I can't reproduce the results you're getting. This is mostly because ice seems to be broken: It always generates a .desktop file with StartupWMClass=Chromium, even when picking Firefox. Never an app-specific one. The resulting Firefox window also doesn't have a special WM_CLASS.

Where did you install ice from? I should try using the same version you have.
Comment 16 evea 2018-06-08 13:10:38 UTC
Oh I am very sorry, I am using an edited version because we tried to fix this issue, and it does not seem to be in the master yet.

Please apply these two patches:
https://github.com/peppermintos/ice/compare/master...eversins:patch-1
https://github.com/eversins/ice/compare/master...eversins-patch-1?quick_pull=1#diff-0


The difference is:
We start FF with its own WM_CLASS:
--class=' + profileid + '
And the *.desktop file also gets a StartupWMClass=profileid

Thanks.
Comment 17 Eike Hein 2018-06-11 07:16:05 UTC
Works correctly for me: https://youtu.be/2Z7tWMi5sGE

[eike@ehl1 ~/.config ]$ grep iconData plasma-org.kde.plasma.desktop-appletsrc
[eike@ehl1 ~/.config ]$
Comment 18 Eike Hein 2018-06-11 07:17:31 UTC
This is using git master and not 5.12, but I'm not aware of any relevant code changes ... I'll try again with the 5.12.2 tag though (note this is an outdated version of 5.12.2).
Comment 19 Eike Hein 2018-06-11 07:19:50 UTC
I retried this with v5.12.2 of both libtaskmanager and the Task Manager applet and can't reproduce it there either, sorry.

Can you check your system's taskmanagerrulesrc (or your own if you wrote one) if there's anything suspicious in there?
Comment 20 evea 2018-06-11 13:46:50 UTC
How do I check my taskmanagerrulesrc?

I just tested it with a default Panel to make sure and I get the same bug. I did not change any Plasma settings which I am aware of and I am not the only one with this problem.

I am currently on Plasma 5.12.5-2 on Manjaro KDE (Arch).
Comment 21 Eike Hein 2018-06-12 07:11:50 UTC
> How do I check my taskmanagerrulesrc?

You search your system for the filename and open the files you find in a text editor :).

And please do always test with the default Task Manager, not Latte since I'm not testing with that and don't know what additional things its code may do.
Comment 22 evea 2018-06-13 04:14:21 UTC
Nothing relevant in there.

/etc/xdg/taskmanagerrulesrc
[Mapping]
Gimp-2.8=GIMP
Google-chrome=Google Chrome
Google-chrome-stable=Google Chrome
Systemsettings=System Settings
oracle-ide-boot-Launcher=Oracle SQL Developer
Dragon=dragonplayer

[Settings]
ManualOnly=Wine
MatchCommandLineFirst=perl
TryIgnoreRuntimes=perl
Comment 23 galder 2022-01-30 16:11:02 UTC
Looks like an old issue. Setting it to needs more info.
Please try with a newer version(plasma 5.23.5) and if this is not an issue any more let us know.
Bugs placed into NEEDSINFO status will receive a reminder if the ticket:

    Is at least 15 days old
    Has not received any comment within 15 days

If a bug remains in NEEDSINFO for another 15 days with no comment, it will be closed as RESOLVED > WORKSFORME.
If a bug remains in NEEDSINFO with a comment provided within less than 15 days, no action will be taken (as it does not meet the above criteria).
Comment 24 Bug Janitor Service 2022-02-14 04:36:21 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 25 Bug Janitor Service 2022-03-01 04:36:36 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!