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.
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.
Both Konqueror windows show the Konqueror icon in the taskbar, the planet with the gear around it.
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.
Additional details: This is with task grouping off, and it's about the "classic" task manager, not the "icon-only" one.
This is by design.
Can it be discussed that it's really annoying? Would it hurt to make it optional?
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.
Ok, thanks for the detailed reasoning!
To me, this is really a step backwards, but I understand why it's been done. Thank you.
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.
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 =)
It basically means writing out a new .desktop file, yep, with category or ShowIn metadata to avoid cluttering menus.
Is there a way to force the old-style behaviour for a specific app, for example Chromium?
@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?
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.
Hello! So, could somebody please advise how to solve this problem?
*** Bug 373903 has been marked as a duplicate of this bug. ***
*** Bug 375601 has been marked as a duplicate of this bug. ***
It's a shame that this has been set as wontfix.
This is one of the numerous regressions between KDE4 and KDE5.
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?
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.
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.
I will keep on documenting everything I know about this issue here:
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?
Around which version or which branch was the feature removed?
Thank you for your help.
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.
(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!
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
It would be nice if this can be formed as a widget option.
Thank you artem and Christoph.
This is what I have so far:
$ locate konqueror.desktop
There was a line that said:
I replaced it with:
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?
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?
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
Please test the following and tell us if it works:
$ locate konqueror.desktop
On my system, I found this:
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.
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.
Created attachment 103788 [details]
This is the actual patch.
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.
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):
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.
Note to distros: Please don't apply this patch as it will lead to the bugs described above.
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.
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.
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.
Created attachment 104664 [details]
Happy guessing which konqueror entry might be the right one to click on.
(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.
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:
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.... :(
(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:
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.
(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.
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 ...
*** Bug 383017 has been marked as a duplicate of this bug. ***
*** Bug 384099 has been marked as a duplicate of this bug. ***
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!
> 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
*** Bug 382142 has been marked as a duplicate of this bug. ***
(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
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 ;)
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.
(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.