Konqueror taskbar icon

This is a wiki page. Be bold and improve it!

If you have any questions about the content on this page, don't hesitate to open a new ticket and we'll do our best to assist you.


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

Konqueror does not use 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.

With a simple patch:


It's amazing that only a very simple patch war required to fix the regression and restore sanity...

Which button to click??
Happy guessing which konqueror entry might be the right one to click on. Screenshot contributed by OpenSUSE user Andreas Kilgus.

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

"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

"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.



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:

git clone git://anongit.kde.org/plasma-workspace.git/

See the code online:


Notes on the current work:


Within plasma-workspace:

QIcon XWindowTasksModel::Private::icon(WId window)
    const AppData &app = appData(window);

    if (!app.icon.isNull()) { // Where is AppData::icon::isNull() defined?
        return app.icon;

    QIcon icon;

    icon.addPixmap(KWindowSystem::icon(window, KIconLoader::SizeSmall, KIconLoader::SizeSmall, false));
    icon.addPixmap(KWindowSystem::icon(window, KIconLoader::SizeSmallMedium, KIconLoader::SizeSmallMedium, false));
    icon.addPixmap(KWindowSystem::icon(window, KIconLoader::SizeMedium, KIconLoader::SizeMedium, false));
    icon.addPixmap(KWindowSystem::icon(window, KIconLoader::SizeLarge, KIconLoader::SizeLarge, false));

    return icon;


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


# mkdir -p /etc/portage/kde-plasma/plasma-workspace

Git this patch:

Place working patch there, then:

# emerge -a plasma-workspace

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

killall plasmashell


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.

Issues related to this page:

ProjectSummaryStatusPriorityCategoryLast updatedAssigned to
Linux softwareKonqueror tabs in taskbar do not show site's fa…activenormalbug report33 weeks 4 days