Konqueror taskbar icon

Description

In KDE 4, the konqueror tab in the taskbar displayed the favicon of the web site that was being browsed. With many konqueror windows open, one could thus easily determine with a glance at the taskbar which web site is on each window. Thus, a user could easily organize its workflow by organizing tabs belonging to the same web site within the same browser window, and opening new web sites in new windows. It's particularly useful when regularly switching between 2 or 3 web sites that one uses a lot.

However, in KDE 5, this feature was completely removed from Konqueror. The icon is always the standard Konqueror icon, so that one can no longer easily differentiate between windows/web sites.

Why is this feature important

With a simple patch:

Justifications for removal

According to developers1, there are many reasons why they preferred removing the feature.

Here is a breakdown:

Launcher icon

When launching a web page with konqueror (e.g. when opening a bookmark, or following a link in an email), the launcher (the original view within konqueror before any web page is loaded) may not have any information about the web site, and may not know its favicon. The launcher would show the default konqueror icon until such a time when the web page is fully loaded. If konqueror were to change the icon, the switch may surprise some users.

Counter arguments:

1) Konqueror was operating this way before. Why can't it continue to, even as an option?

2) Certainly this is not a technical limitation.

3) The problem being described is at best minor, certainly compared to the loss of productivity when many konqueror windows are open and one cannot efficiently differentiate between them.

Custom icon theme

Some users use a custom icon theme, which may contain a custom konqueror icon. The favicon would override this custom setting.

Counter arguments:

1) How many users actually care that much about custom icon themes? Do those theme settings affect their productivity??

2) It is still not a technical limitation to have the feature reinstated.

3) We could still have an option users could select according to their usage habits.

Legacy applications

Quote:
"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"

Counter arguments:
1) What legacy applications are we talking about here??
What is the connection with Konqueror?

2) Are we worried about low resolution favicons, here? Let the user decide what they prefer! According to some people's usage habits, a somewhat ugly-looking favicon is a small price to pay for increased productivity.

3) It's still not a technical hurdle. We are still talking about a matter of choice, appreciation and priorities.

Wayland support

Wayland does not support window icons. If kwin users were to have this option, then wayland wouldn't have the same features.

Counter arguments:

1) Seriously??? Wayland is still a work in progress and is far from reaching the level of maturity of kwin.

2) What about users who don't use wayland and don't want to use it, or have no good reason to use it? Why impose on kwin users such a regression?

3) Wayland may not support window icons now, but certainly, such a feature will be implemented at some stage. Do kwin users have to suffer such a regression until wayland has caught up?

4) There is still no technical limitation, as least for kwin users.

Task Manager

Quote:
"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"

Counter arguments:

1) The quote needs clarifications. Are we at last talking about some technical limitation? Which is it exactly? What possible ways would there be to go around it?

2) In any case whatever limitations may exist today did not exist before. What has changed??

3) Regular Konqueror developers may not be willing to re-instate the feature, but one may hope that they will gladly support with information and pointers those who have a strong desire to patch their system.

Code

Repository

The regression is not a konqueror issue per se, but a limitation imposed by Plasma.

To work on the code and fix Plasma, clone the following repository:

See the code online:
https://cgit.kde.org/plasma-workspace.git/

WIP

Notes on the current work:

/usr/share/kde4/services/konqueror.desktop
Icon=konqueror
=>
Icon=

Within plasma-workspace:
libtaskmanager/xwindowtasksmodel.cpp:

openSUSE

Andreas Kilgus offered to create an openSUSE package with the fix applied.

Gentoo

Git this patch:
https://bugs.kde.org/attachment.cgi?id=103788

Place working patch there, then:

After re-emerging, there is no need to reboot. In krunner (ALT F2), do:

then:

Other distributions

Please help us document step by step guides on how to recompile packages manually, with the fix applied, and also list user contributed packages with the fix.

• 1. E.g. in this comment: https://bugs.kde.org/show_bug.cgi?id=369658#c4