Bug 369658

Summary: Different windows from same app show icon defined in .desktop file instead of app-specified icon
Product: [Plasma] plasmashell Reporter: JanKusanagi <jan-bugs>
Component: Task Manager and Icons-Only Task ManagerAssignee: Eike Hein <hein>
Status: REOPENED ---    
Severity: minor CC: artem.rizhov, bugs.kde.org, cfeck, faure, jan-bugs, jjm, kde, kde, kdebuac.rhn, kde_bugs, kde_bugs, plasma-bugs, post, richard.llom
Priority: NOR    
Version: 5.8.0   
Target Milestone: 1.0   
Platform: Mageia RPMs   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: Real life example of a user session where konqueror lacks favicons
2 konqueror tabs in taskbar, with favicon showing
This is the actual patch.
Happy guessing which konqueror entry might be the right one to click on.

Description JanKusanagi 2016-10-03 00:41:30 UTC
If you run a multi-window program, or multiple instances of the same program, like Konqueror for instance, each window might have a different "window icon", visible to the left of the title bar.

In the specific case of Konqueror, the icon will be a sort of sheet icon with the "favicon" icon for the current page painted over a portion of the sheet. That same icon is used in the application switcher (alt+tab), although that depends on the type of switcher you're using of course. I'm using "informative".

The problem here is that while the switcher uses the correct icons, the task manager shows always the application icon as defined in the .desktop file for the application. In the case of Konqueror, that's Konqueror's icon, the planet with the gear around it. So 3 different Konqueror windows look the same, icon-wise, in the taskbar, but they're different (which I find nice) in the application switcher.

Another example would be the Psi Jabber/XMPP client, which shows different icons for individual chats, groupchats, and the main window. Under Plasma 5, all windows show the same icon, the "Psi" logo.

I've verified that this does not happen if the program doesn't have a .desktop file. I've also found mention of this being expected in a pseudo-related bugreport: https://bugs.kde.org/show_bug.cgi?id=365355#c3

Both of the examples I gave are Qt4-based, but for the record, a program of mine, built with Qt 5, suffers from the same issue.

So, to sum up:
Using the icon specified in the .desktop file could be nice for windows that don't set an icon (instead of that generic "X11 icon", but I'd say that, if a window specifies which icon it wants, the task manager should use that one, like the application (task) switcher.

Reproducible: Always

Steps to Reproduce:
1. Open 2 Konqueror windows.
2. Load http://www.mageia.org/en/ in one window and http://planet.debian.org/ on the other.


Actual Results:  
Both Konqueror windows show the Konqueror icon in the taskbar, the planet with the gear around it.

Expected Results:  
One Konqueror window should show with an icon that's a paper sheet with a planet inside, and a Mageia logo (mageia.org's favicon) in a corner. The other window should use a similar icon, but with Debian's logo.
Comment 1 JanKusanagi 2016-10-03 13:58:57 UTC
Additional details: This is with task grouping off, and it's about the "classic" task manager, not the "icon-only" one.
Comment 2 Eike Hein 2016-10-04 08:59:05 UTC
This is by design.
Comment 3 JanKusanagi 2016-10-04 12:24:25 UTC
... ok.

Can it be discussed that it's really annoying? Would it hurt to make it optional?
Comment 4 Eike Hein 2016-10-04 12:45:08 UTC
It's been discussed many times in the past, but here's the lowdown:

* If we don't give precedence to the system icon for an app, it means the icon can change during a transition from launcher to window, which breaks the lifecycle visually and is upsetting to users (-> bug reports)
* Ditto not respecting the user's choice in custom icon theme (app code may load icon assets differently from Plasma, so no consistency is guaranteed) or custom configured icon (menu editor)
* Legacy apps often load icon assets in ways that doesn't give us a hi-res icon we need for hi-dpi systems, causing the icons to look blurry or pixelated
* Wayland doesn't support window icons much less ones that change at runtime, so if this were optional we wouldn't be able to offer this option across windowing systems, further sacrificing consistency
* The Task Manager is not a window list, the buttons it displays are an abstraction over several data sources (launchers, startup notifications, windows (some of which are logically treated as a single entity, e.g. in case of hidden utility windows, or grouping)) and the integrity of this abstraction outweighs providing detailed window metadata

Bottom line: (a) Far more users expect/rely on apps in the Task Manager having a stable, recognizable icon (potentially one they explicitly chose) than on window-specific icons, (b) the quality of the window metadata is low and it's not consistently available across supported windowing systems.
Comment 5 JanKusanagi 2016-10-04 13:16:58 UTC
Ok, thanks for the detailed reasoning!

To me, this is really a step backwards, but I understand why it's been done. Thank you.
Comment 6 Eike Hein 2016-10-04 13:21:52 UTC
Note that application developers have options here, e.g. a chat client could properly register each group chat with the system and give it a custom icon that way. That would have the additional advantage that you could even pin them as launchers, find them in KRunner, ...

No this doesn't fit every use case (e.g. website favicons), but for some it's a really good way to go.
Comment 7 JanKusanagi 2016-10-04 13:30:05 UTC
I'm sorry to abuse this bugreport like this, but one last thing:

> Note that application developers have options here, e.g. a chat client could properly register each group chat with the system and give it a custom icon that way.

Do you have any links or keywords about how that's done? I imagine maybe it has something to do with additional .desktop file properties, or individual window properties/flags other than the icon, but I'd like to point some developers that way. And it could enhance my own programs too =)

Again, thanks!
Comment 8 Eike Hein 2016-10-04 13:32:37 UTC
It basically means writing out a new .desktop file, yep, with category or ShowIn metadata to avoid cluttering menus.
Comment 9 artem 2016-10-11 18:52:50 UTC
Is there a way to force the old-style behaviour for a specific app, for example Chromium?
Comment 10 Kai Uwe Broulik 2016-10-11 18:59:21 UTC
@artm: There is not. However, Chromium webapps should just work since they install a desktop file for themselves (show up in the launcher menu) and we also have a mapping heuristic for them. Is that what you need or can you be more specific why you would need Chromium to provide an icon?
Comment 11 artem 2016-10-12 10:50:48 UTC
Thanks for the reply. Unfortunately this is not what I need. I'm trying to implement a feature like that one in Konqueror, i.e. to make the window icon changing to display the current site favicon. However, the change is not reflected in the KDE taskbar.

I also agree with the topicstarter about the inconvenience when all buttons have the same app icon. This also makes problem with Skype, because I can't distinguish the contact list from the chat window. Gimp also makes problem because it makes a lot of windows with similar icon on the KDE taskbar. So I can't click the right button on the taskbar in many cases, and have to guess and search for the desired window.

I understand the reason and the idea of the current design. The icons look much more professional now. But while they look so, now they do not work so. You also may think about this buttons like about some abstractions, but people probably want to switch between real windows in most cases. I use KDE because this is most professional and flexible DE on Linux. But where does it go now? I hope it will not be similar to Unity in the future, really :)

So, finally, I want to say, it would be great if the user may choice between "nice" and "useful" icons somehow. Replacing own window icon with a nice static vector icon seems like a workaround, but not the real solution to the problems. This breaks the usual experience.
Comment 12 artem 2016-10-17 18:08:40 UTC
Hello! So, could somebody please advise how to solve this problem?
Comment 13 Christoph Feck 2016-12-21 03:17:59 UTC
*** Bug 373903 has been marked as a duplicate of this bug. ***
Comment 14 Christoph Feck 2017-01-27 15:25:29 UTC
*** Bug 375601 has been marked as a duplicate of this bug. ***
Comment 15 Anguo 2017-01-31 16:54:37 UTC
It's a shame that this has been set as wontfix.
This is one of the numerous regressions between KDE4 and KDE5.

Of all of konqueror's shortcomings, this bug is the one that affects me the most in my daily use. Despite many bugs in css and javascript rendering, Konqueror is still the best browser to use when we care about KDE integrations and especially Plasma Activities.

I am going to try to dig up the code that was ripped, and see if I can patch konqueror to restore this functionality.
I am currently cloning git://anongit.kde.org/kde-baseapps.git. I hope this is the right repository.

Could developers who are familiar with the Konqueror code base provide me with pointers as to about when was the feature removed, and which files in the git history should I look into?
Comment 16 Christoph Feck 2017-02-01 00:29:50 UTC
Anguo, this is not a Konqueror regression, but the taskmanager in the Plasma5 Workspace simply does not show window icons, but application icons.

See comment #4 for an explanation of the (multiple) reasons why this has been changed.
Comment 17 Anguo 2017-02-02 16:01:27 UTC
Created attachment 103775 [details]
Real life example of a user session where konqueror lacks favicons

This is a real life example of a user session. One Konqueror window is open on a wikipedia page, the other is open on the user's personal web page dealing with the same topic. The user was referring to Wikipedia while working on an article.
 Can you quickly make out at a glance which window is which? There is an obvious clue if one looks carefully, but that's the point: one has to read the fine text to decide on which taskbar item to click in order to continue working.
Comment 18 Anguo 2017-02-02 16:05:33 UTC
I will keep on documenting everything I know about this issue here: 
http://linux.overshoot.tv/wiki/konqueror_taskbar_icon 
See attached picture example on why this KDE Plasma regression is a nightmare for some of us.
I have posted rebuttals or requests for clarifications on all the points raised in #4.

I am NOT asking konqueror developers to fix this themselves, if they are not willing to do so. I am willing to do the heavy lifting. But I don't know the code base like you do. Please give me a fighting chance of finding a way to patch my system so that I can stop mixing my windows all the time.

Which git repository should I look into?
Which files?
Around which version or which branch was the feature removed?

Thank you for your help.
Comment 19 Anguo 2017-02-02 16:07:16 UTC
Sorry! By "konqueror developers", I mean KDE developers, including Plasma developers. 

Please help me: I know that out of the top of your head you could provide pointers that would save me hours of searching.
Comment 20 artem 2017-02-02 18:41:39 UTC
(In reply to Anguo from comment #19)
> Please help me: I know that out of the top of your head you could provide
> pointers that would save me hours of searching.

Hi Anguo! I'm not a KDE developer, but I think you need the plasma-workspace part from this page https://www.kde.org/info/plasma-5.9.0.php
It probably makes sense to compare the source code with the earlier version to find how the regression was made.

I'll be happy if you fork and patch this widget. Good luck!
Comment 21 Christoph Feck 2017-02-02 19:20:22 UTC
According to the code, it should show the favicons, if there is no icon specified in the .desktop file.

If you can confirm this works, then remove the first four lines from the function 
QIcon XWindowTasksModel::Private::icon(WId window)
defined at https://cgit.kde.org/plasma-workspace.git/tree/libtaskmanager/xwindowtasksmodel.cpp
Comment 22 artem 2017-02-02 19:36:55 UTC
It would be nice if this can be formed as a widget option.
Comment 23 Anguo 2017-02-03 04:13:05 UTC
Thank you artem and Christoph.
:)

This is what I have so far:
$ locate konqueror.desktop
/usr/share/kde4/services/konqueror.desktop

There was a line that said:
Icon=konqueror
I replaced it with:
Icon=
and saved the file.
I launched a new KDE session on another tty, opened a wikipedia page but no luck. I didn't reboot: I don't know if it makes a difference with regard to icon caching, etc.

Meanwhile, I am cloning:
git clone git://anongit.kde.org/plasma-workspace.git/
Christoph, I'll check the function you mention, create a custom patch, rebuild (luckily, it's so very easy to do within gentoo!), reboot and report back...

If it fails, where else should I look into?
Thanks.
:)
Comment 24 Anguo 2017-02-03 04:49:00 UTC
Hmmm... interesting:
after patching and re-emerging plasma-workspace, it says:

>>> Installing (1 of 1) kde-plasma/plasma-workspace-5.8.5::gentoo
 * Updating .desktop files database ...    

Where is this .desktop files database?
Comment 25 Anguo 2017-02-03 12:55:58 UTC
OMG! Christoph! I can't believe the fix was so easy!
I am so happy. :D At last I can make some sense of the tabs in my taskbar again!
I don't know how long it took you to dig out the right method, but you certainly saved me days (at the very least) of hair-pulling on my side! Still, your time is at least as valuable as my own, so I greatly appreciate the help you provided!

Now, on the technical side of things, I did two tests; the first one was not successful, the second was.

The first time, I simply did what I mentioned above. I simply edited konqueror.desktop so that I had "Icon=" instead of "Icon=konqueror". I didn't log out nor reboot, but I started another session: there was no change.

The second time, to be sure to stack the cards on my favour, I did 2 things.
I hadn't found the definition of AppData::icon::isNull() so I didn't know if an empty string would count as Null. Thus, I completely deleted the "Icon=" line from the konqueror.desktop file. ALSO, I patched the file Christoph mentioned and recompiled the package, and installed it (within gentoo, that's all done with a single 'emerge' command), then rebooted the computer. After reboot, I was back in sanity land! Yeah! :D

@artem,
Please test the following and tell us if it works:
do:
$ locate konqueror.desktop
On my system, I found this:
/usr/share/kde4/services/konqueror.desktop
Completely remove the Icon= line, save the file then reboot. See if it's enough to remove the regression and fix your system.

The simplicity of the fix proves that the reasons given in #4 are complete bullshit. It'd take 30 minutes for an experienced Plasma developer to code a setting into systemsettings and look up that setting within XWindowTasksModel::Private::icon(WId).
A warning could be provided for the user, warning them about low-resolution favicons, potential inconsistencies, etc.... none of which I experience at this happy hour.
Comment 26 Anguo 2017-02-03 13:02:54 UTC
Created attachment 103787 [details]
2 konqueror tabs in taskbar, with favicon showing

A simple patch makes all the difference, with the favicon superimposed in the corner of the konqueror icon.
Comment 27 Anguo 2017-02-03 13:06:22 UTC
Created attachment 103788 [details]
This is the actual patch.
Comment 28 artem 2017-02-05 16:37:11 UTC
@Anguo,
I've tried to remove the "Icon=" line and this did the tick for Gimp, but not for Konqueror. It seems this feature has been removed from the Konqueror settings.
Comment 29 Anguo 2017-02-06 14:18:59 UTC
I confirm that merely editing the .desktop file is not enough.

After recompiling and installing the fixed package, I noticed that to test, it was enough to do in krunner (alt + f2):
killall plasmashell
then again:
plasmashell

@artem,
I don't know what distro you use, but I hope you'll get help about getting the source, applying the simple patch and recompiling the package. 

You may also try to file a bug report in your distro's tracker and ask them if they would do the sensible thing. Distros regularly have custom patches for some packages.
Comment 30 Eike Hein 2017-02-07 07:27:36 UTC
Note to distros: Please don't apply this patch as it will lead to the bugs described above.
Comment 31 Anguo 2017-02-07 07:51:07 UTC
What you refer to as bugs are slight visual ugliness in some places. I much prefer those to the complete unusability of the current default behaviour. Since applying the fix, my workflow and efficiency has improved a lot.


Actually, fixing this regression allowed me to discover another reason why I previously always confused my konqueror tasks. The default plasma behaviour is that the tab orders in the taskbar is not fixed but depends on which tab in the konqueror window is currently active. It happened invisibly without me ever noticing before, so that I was getting almost crazy: "I could have sworn that the window opened on that site was the right-most task in the taskbar".
Within 5 minutes of fixing the regression, what was happening without me noticing, all of a sudden became apparent. It was night and day. 

The regression is a huge usability nightmare, at least for many of us, judging by the number of duplicate reports.

KDE has always been the DE which offered the most customisability, giving users the most freedom.

It would take any seasoned KDE developer no more than 30 minutes to offer a settings and take it into account in the patched method.

I dare take a chance at reopening this bug report, because:

1) We have a choice between slight visual inconsistencies versus a huge usability regression. Which one is more important?

2) hiding other existing bug with the use of a regression and dumbing down a software is akin to sweeping the dust under the carpet. Let the dust be apparent until someone is motivated enough to fix it in a more appropriate manner.

3) I am concerned about other users who experience the same problems. My own system is fixed so I am happy for myself.

4) A single setting is all what it would take to have the best of both world, giving the choice back to the end users.
Comment 32 Eike Hein 2017-02-07 07:57:10 UTC
We're not going to add options that (a) we can't offer on Wayland anyway and (b) allow configuring the product in a known-broken state. This has been discussed at length above. You're being selective to suit your personal views, which we can't responsibly afford to.
Comment 33 Eike Hein 2017-02-07 08:20:16 UTC
About the (unrelated) sorting issue, this has come up in user feedback 2-3 times lately and I've submitted a patch for review: https://phabricator.kde.org/D4469

I expect this to get into 5.8.x and 5.9.x in some form soon.
Comment 34 Andreas Kilgus 2017-03-21 04:24:09 UTC
Created attachment 104664 [details]
Happy guessing which konqueror entry might be the right one to click on.
Comment 35 Andreas Kilgus 2017-03-21 05:01:55 UTC
(In reply to Anguo from comment #31)
> What you refer to as bugs are slight visual ugliness in some places. I much
> prefer those to the complete unusability of the current default behaviour.
Thanks for your fix. I spent hours looking for where and when I might have messed things up that much so that the favicons of all my konqueror instances in the taskbar have gone. I simply couldn't imagine, that this is not caused by misconfiguration or missing or incompatible packages. Finding this bug report eventually I learned that it's because of me switching from KDE4 to plasma5. A pleasure to read that it is "by design" to render my taskbar partly useless - see attachment https://bugs.kde.org/attachment.cgi?id=104664.

Well, upstream says "WONTFIX" - but thanks to you now there's a way to regain this part of my workflow. Perhaps I can offer packages with your patch applied in openSUSEs build service.
Comment 36 Anguo 2017-03-22 08:16:04 UTC
Thanks Andreas.

The fix was kindly provided by Christoph in  #21.

I hope you don't mind, I have added your screenshot to the wiki page here:
http://linux.overshoot.tv/wiki/konqueror_taskbar_icon 
I still don't understand the very weak arguments by upstream against fixing this regression.
I know it's a usability nightmare. I want to continue helping affected users and keep the wiki page updated. Can you contribute notes about OpenSuse?

More, major regressions are coming soon with Konqueror 2016.12.... :(
Comment 37 Andreas Kilgus 2017-03-22 16:31:44 UTC
(In reply to Anguo from comment #36)

> The fix was kindly provided by Christoph in  #21.
Oh. Sorry, Christoph, I obviously lost track of the origin of the patch.

> I hope you don't mind, I have added your screenshot to the wiki page here:
> http://linux.overshoot.tv/wiki/konqueror_taskbar_icon
Feel free to do so.

> I still don't understand the very weak arguments by upstream against fixing
> this regression.
> I know it's a usability nightmare. I want to continue helping affected users
> and keep the wiki page updated. Can you contribute notes about OpenSuse?
At the moment there is nothing special to write concerning openSUSE.

> More, major regressions are coming soon with Konqueror 2016.12.... :(
Well, one has to differentiate. Most of the time I can completely understand regressions due to lack of manpower or technical difficulties.
Wilfully holding back / removing (even as an option) existing functionality at least partly wanted by users is a different matter. And noone should be surprised that something like that is not received with cheers - regardless how valuable one's work might be elsewise.
Comment 38 Andreas Kilgus 2017-05-29 06:51:23 UTC
(In reply to Anguo from comment #36)
> I know it's a usability nightmare. I want to continue helping affected users
> and keep the wiki page updated. Can you contribute notes about OpenSuse?

I branched the Frameworks5 (Leap 42.2) and Frameworks5 LTS repos. Packages with patch applied: http://repos.opensuse.org/repositories/home:/akilgus:/branches:/KDE:/
konqueror.desktop has to be edited ("Icon=") manually.

Works for me. But there might come future versions of plasma5-workspace rendering this patch inapplicable.
So: Can anybody hint me about the easiest way / starting point to implement a simple alternative taskbar? Can something like that be done using Plasmate/QML/JavaScript?

That much wasted time just because the unwillingness to make an existing feature (at least in a still widely used software constellation) an option for the ones relying on it instead of cutting it out completely. I don't get it ...
Comment 39 Eike Hein 2017-08-02 08:38:09 UTC
*** Bug 383017 has been marked as a duplicate of this bug. ***
Comment 40 Eike Hein 2017-08-28 10:07:42 UTC
*** Bug 384099 has been marked as a duplicate of this bug. ***
Comment 41 Richard Llom 2017-08-30 11:48:45 UTC
What I get from reading through this:
it is still possible (w/o patching) to have individual task icons for a multi-window program by writing a specific .desktop file, right?

So how to write that specific desktop file? This has already been asked in comment #7, yet there has not been given an extensive answer so far.
(And I wasn't able to find one via google either.)

To the Plasma Team: Please provide such an comprehensive guide!


It would be much appreciated by app developers and users alike, thanks!
Comment 42 Eike Hein 2017-08-31 08:48:25 UTC
> it is still possible (w/o patching) to have individual task icons for a multi-window program by writing a specific .desktop file, right?

1. make sure the window has a different WM_CLASS
2. deploy a .desktop file with a matching name or StartupWMClass key value
Comment 43 Eike Hein 2017-09-20 09:02:15 UTC
*** Bug 382142 has been marked as a duplicate of this bug. ***
Comment 44 David Faure 2018-03-04 22:58:30 UTC
(In reply to Eike Hein from comment #4)
> * If we don't give precedence to the system icon for an app, it means the
> icon can change during a transition from launcher to window, which breaks
> the lifecycle visually and is upsetting to users (-> bug reports)

That could be fixed by having specific API for an app to set the window icon, i.e. it wouldn't be done by most applications, only by those that really need it (like a webbrowser, which can have many windows open that need to be distinguished). Many other apps either show very few windows (korganizer, zanshin), or have no way to distinguish windows with icons anyway (kmail, kwrite, konsole). And for these I totally understand the consistency argument, but that's forgetting the webbrowser use case, see the screenshots like "Happy guessing..." in this report.

> * Ditto not respecting the user's choice in custom icon theme (app code may
> load icon assets differently from Plasma, so no consistency is guaranteed)
> or custom configured icon (menu editor)

Same reasoning here, same solution.

> * Legacy apps often load icon assets in ways that doesn't give us a hi-res
> icon we need for hi-dpi systems, causing the icons to look blurry or
> pixelated

Ditto. Legacy apps wouldn't be using this new API.

> * Wayland doesn't support window icons much less ones that change at
> runtime, so if this were optional we wouldn't be able to offer this option
> across windowing systems, further sacrificing consistency

What plasma developers don't seem to understand is that 99% of the users are using X11, not wayland... As long as my system runs X11, I don't really care what wayland's limitations are. If wayland is designed in a way that breaks this use case, then that's a wayland bug.

> * The Task Manager is not a window list, the buttons it displays are an
> abstraction over several data sources (launchers, startup notifications,
> windows (some of which are logically treated as a single entity, e.g. in
> case of hidden utility windows, or grouping)) and the integrity of this
> abstraction outweighs providing detailed window metadata

That's developer reasoning, which shouldn't outweigh usability ;)
Comment 45 Eike Hein 2018-03-05 06:17:14 UTC
I'm OK with you creating this API. Unlike KWin, libtaskmanager is not feature-frozen on X11 currently. However, I won't accept a patch for X11 without a working Wayland implementation at the same time.
Comment 46 Nohus 2023-12-15 17:20:42 UTC
(In reply to Eike Hein from comment #42)
> 1. make sure the window has a different WM_CLASS
> 2. deploy a .desktop file with a matching name or StartupWMClass key value

I am running into this issue and tried your solution, but it does not work. I created two .desktop files, differing in the StartupWMClass property, but it looks to be ignored. Either .desktop file works by itself and correctly sets the icon on the task bar, but when both are present one takes precedence and the other is ignored. I have confirmed the value is correct with xprop. I am unsure how I can debug this further. I am trying to develop an application for KDE and this issue is a big usability problem.