[kwin] [Bug 351055] New: Icons are fuzzy (low resolution) in Task Switcher with Large Icons

[Vincenzo]

https://bugs.kde.org/show_bug.cgi?id=351055

Bug ID: 351055
Summary: Icons are fuzzy (low resolution) in Task Switcher with
Large Icons
Product: kwin
Version: 5.3.1
Platform: Kubuntu Packages
URL: Loading Image...
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: NOR
Component: general
Assignee: kwin-bugs-***@kde.org
Reporter: ***@gmail.com

When using the Task Switcher with Large Icons (System Settings -> Window
Management -> Task Switcher), some applications have fuzzy icons, probably due
to low resolution samples being rendered there.

I am not sure if this is a problem of the application rather than KDE, but the
same applications have icons with the right resolution (i.e., sharp) in Unity,
e.g., Zim.

In the picture here
http://pasteboard.co/2xqvubnV.png
It is visible that only Dolphin has a sharp icon.

Atom was not running at the moment of the screenshot, but that also has a sharp
icon.

Reproducible: Always

Steps to Reproduce:
1. Press ALT+TAB when the Task Switcher is the Large Icons one.

Actual Results:
Fuzzy, blurry icons

[Thomas Lübking]

Dette indlæg kan være upassende. Klik for at få det vist.

[Vincenzo]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #2 from Vincenzo <***@gmail.com> ---
$ xprop
_NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_SKIP_PAGER
_KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 15494598
_NET_WM_USER_TIME(CARDINAL) = 15494505
_KDE_NET_WM_SHADOW(CARDINAL) = 81804309, 81804311, 81804312, 81804313,
81804314, 81804315, 81804316, 81804317, 12, 12, 12, 12
_KDE_NET_WM_BACKGROUND_CONTRAST_REGION(_KDE_NET_WM_BACKGROUND_CONTRAST_REGION)
= 0x1, 0x1, 0x246, 0xb6, 0x3f1ed741, 0xbd73d3a2, 0xbd73d3a2, 0x0, 0xbe4d0fe8,
0x3ef5a102, 0xbe4d0fe8, 0x0, 0xbca59c07, 0xbca59c07, 0x3f28e79b, 0x0,
0x3f4cccce, 0x3f4cccce, 0x3f4cccce, 0x3f800000
_KDE_NET_WM_BLUR_BEHIND_REGION(CARDINAL) = 1, 1, 582, 182
_NET_WM_ICON(CARDINAL) = Icon (32 x 32):


░ ░░░░░░░░░░░░░░░░░░░
░░░ ░░░░░░░░░░░░░░░▒░░░
░░░░░░░░░░░░░░░░░▒▒░░░░
░░░░░░░░░░░░░░░░░▒▒░░░░░
░░░░░░░░░░░░░░░░▒▒▒░░░░░░
░░░░░░ ░░░░ ░░░▒▒▒░░░░░░░
░░░░░░░ ░░░ ▒▒▒▒░░░░░░░░
░░░░░░░░░░░░ ░▒▒░░░░░░░░░
░░ ░░░░░░░░░░░░░░ ░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░ ░░░░░░░░░░
░░░░░░░░░ ░░░░░░░ ░░░░░░░░░
░░░░░░░░░ ░░░░░░ ░░░░░░░░░░░
░░░░░░░░░ ░░░░░ ░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░ ░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░ ░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░ ░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░ ░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

▒ ▒▒
▒ ▒▒




Icon (22 x 22):



▒▒ ░░
▒▒ ░▒▒░
░▒▒▒░
░▒▒▒░
░▒▒▒░
░▒▒▒░
░▒░ ░▒▒▒░
▒▒▒ ░▒▒▒░
░▒░ ░▒▒░
░░


▒▒
▒▒▒▒
▒▒▒▒
▒▒





XdndAware(ATOM) = BITMAP
_NET_WM_NAME(UTF8_STRING) = "KWin"
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x1, 0x0, 0x0, 0x0
_NET_WM_WINDOW_TYPE(ATOM) = _KDE_NET_WM_WINDOW_TYPE_OVERRIDE,
_NET_WM_WINDOW_TYPE_NORMAL
_XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x1
WM_CLIENT_LEADER(WINDOW): window id # 0x4e00002
WM_HINTS(WM_HINTS):
Client accepts input or input focus: True
Initial state is Normal State.
_NET_WM_PID(CARDINAL) = 1743
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 82679225
WM_CLASS(STRING) = "kwin_x11", "kwin"
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING,
_NET_WM_SYNC_REQUEST
WM_NORMAL_HINTS(WM_SIZE_HINTS):
user specified location: 672, 512
user specified size: 584 by 184
window gravity: Static

[Thomas Lübking]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #3 from Thomas Lübking <***@gmail.com> ---
Sorry, but I meant not of the tabbox, but of such window which is represented
by a "blurry" (scaled) icon.

[Vincenzo]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #4 from Vincenzo <***@gmail.com> ---
Ahaha, my fault :).

Here is the output from google-chrome:



$ xprop
XdndTypeList(ATOM) = STRING, TEXT, UTF8_STRING, text/plain, XdndDirectSave0,
text/html, text/x-moz-url, chromium/x-renderer-taint, application/octet-stream
_NET_WM_ICON_GEOMETRY(CARDINAL) = 408, 1169, 39, 27
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE,
_NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_MAXIMIZE_VERT,
_NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_FULLSCREEN,
_NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE
_KDE_NET_WM_FRAME_STRUT(CARDINAL) = 6, 6, 32, 6
_NET_FRAME_EXTENTS(CARDINAL) = 6, 6, 32, 6
_NET_WM_DESKTOP(CARDINAL) = 0
_KDE_NET_WM_ACTIVITIES(STRING) = "01031bf8-1bd6-42c8-b1b5-4c19bb792dbc"
WM_STATE(WM_STATE):
window state: Normal
icon window: 0x0
_NET_WM_STATE(ATOM) =
_NET_WM_USER_TIME(CARDINAL) = 16015144
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified location: 189, 150
program specified minimum size: 655 by 63
WM_NAME(UTF8_STRING) = "[kwin] [Bug 351055] Icons are fuzzy (low resolution) in
Task Switcher with Large Icons - [e-mail] - Gmail - Google Chrome"
_NET_WM_NAME(UTF8_STRING) = "[kwin] [Bug 351055] Icons are fuzzy (low
resolution) in Task Switcher with Large Icons - [e-mail] - Gmail - Google
Chrome"
XdndAware(ATOM) = BITMAP
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x0, 0x1, 0x0, 0x0
_KDE_NET_WM_USER_CREATION_TIME(CARDINAL) = 124281
_NET_WM_ICON(CARDINAL) = Icon (64 x 64):



░░░░░░░░░░░░
░░░░░░░░░░░░░░░░░▒░░
░▒░░░░░░░░░░░░░░░░░░▒▒▒░
░▒▒░░░░░░░░░░░░░░░░░░░▒▒▒▒▒▒
░▒▒▒▒░░░░░░░░░░░░░░░░░░▒▒▒▒▒▒▒▒░
▒▒▒▒▒▒▒▒░░░░░░░░░░░░░░▒▒▒▒▒▒▒▒▒▒▒▒
░▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
░░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
░░░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░ ░░░░░░░░░░░░░░░░░░░░░░░
░░░░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░ ░░░░░░░░░░░░░░░
░░░░░░▒▒▒▒▒▒▒▒▒▒▒▒▒░ ░░░░░░ ░░░░░░░░░░
░░░░░░░░▒▒▒▒▒▒▒▒▒▒▒ ░░░░░░░░░░ ░░░░░
░░░░░░░░▒▒▒▒▒▒▒▒▒▒ ░░░░░░░░░░░░░░
░░░░░░░░░▒▒▒▒▒▒▒▒░ ░░░░░░░░░░░░░░░░
░░░░░░░░░░▒▒▒▒▒▒▒░ ░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░▒▒▒▒▒▒ ░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░▒▒▒▒▒▒ ░░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░▒▒▒▒░ ░▒░░░░░░░░░░░░░░░░░░▒ ░
▒░░░░░░░░░░░▒▒▒▒ ░▒▒▒░░░░░░░░░░░░░░░▒▒░ ░
▒░░░░░░░░░░░░▒▒▒ ▒▒▒▒▒▒░░░░░░░░░░░▒▒▒▒░ ░
▒░░░░░░░░░░░░▒▒▒ ▒▒▒▒▒▒▒▒▒▒▒░▒▒▒▒▒▒▒▒▒▒ ░
▒░░░░░░░░░░░░░▒▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ░
▒░░░░░░░░░░░░░░▒ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ░
▒░░░░░░░░░░░░░░▒░ ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░ ░
▒░░░░░░░░░░░░░░░░ ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░ ░
░▒░░░░░░░░░░░░░░░ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ░░
░▒░░░░░░░░░░░░░░░ ░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░ ░░
░▒░░░░░░░░░░░░░░░░ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ░
▒░░░░░░░░░░░░░░░░ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ░░
▒▒░░░░░░░░░░░░░░░░ ▒▒▒▒▒▒▒▒▒▒▒▒▒▒ ░░
░▒░░░░░░░░░░░░░░░░░ ▒▒▒▒▒▒▒▒▒▒▒░ ░ ░░░
▒▒░░░░░░░░░░░░░░░░░ ░▒▒▒▒▒▒░ ░ ░░░
░▒▒░░░░░░░░░░░░░░░░░░ ░▒░ ░░░░
░▒▒░░░░░░░░░░░░░░░░░░░░░ ░░▒▒░ ░░░░░
▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░▒▒░ ░░░░
░▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░▒▒░ ░░░░░
░▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░▒░ ░░░░░░
▒▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░ ░░░░░░
░▒▒▒▒▒░░░░░░░░░░░░░░░░░░░░░░░ ░░░░░░░
░▒▒▒▒▒░░░░░░░░░░░░░░░░░░░░░░ ░░░░░░░░
░▒▒▒▒▒░░░░░░░░░░░░░░░░░░░░ ░░░░░░░░░
▒▒▒▒▒▒▒░░░░░░░░░░░░░░░░░ ░░░░░░░░░░
░▒▒▒▒▒▒▒░░░░░░░░░░░░░░░ ░░░░░░░░░░░░
░▒▒▒▒▒▒▒▒▒░░░░░░░░░░░░ ░░░░░░░░░░░░░░░
░▒▒▒▒▒▒▒▒▒▒▒▒░░░▒▒░░░░░░░░░░░░░░░░░░
░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░░░░░░░░░
░▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░░░░░░░░
░▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░░░░░░
░░▒▒▒▒▒▒▒▒░░░░░░░░░░░░
░░▒▒▒▒░░░░░░░░░░





WM_WINDOW_ROLE(STRING) = "browser"
WM_CLASS(STRING) = "Google-chrome-stable", "Google-chrome-stable"
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_PID(CARDINAL) = 2334
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "vince-Latitude-E7240"
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, _NET_WM_PING

[Thomas Lübking]

https://bugs.kde.org/show_bug.cgi?id=351055

Thomas Lübking <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Summary|Icons are fuzzy (low |Icons are upscaled in
|resolution) in Task |"Large Icons" Task Switcher
|Switcher with Large Icons |

--- Comment #5 from Thomas Lübking <***@gmail.com> ---
Thanks.
Together with bug #350645 it seems icons are now up-, but no longer downscaled
(ie. the exact opposite of what was intended)

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351055

***@gmail.com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #6 from ***@gmail.com ---
(In reply to Thomas Lübking from comment #1)

Post by Thomas Lübking
afaiu, unity doesn't use the icons on the window at all but guesses them
from the class hints (and then loads them from disk)
we briefly discussed that, but the proposed unity(?) function was rather one
giant hack with lots of string mappings

Is there a bug open for that? It seems to me, an idiot, to be the obviously
correct strategy.

Why would we want to look at crappy quality icons or inconsistently sized icons
when our computers have the equally sized, full quality icons readily
available? Heck, the large icon task switcher often doesn't even grab the icon
from the theme at all! The icon grabbing behavior appears to be totally insane
depressingly sloppy, but I can't find any other bugs open about this, so if you
know of any, please let me know.

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #7 from ***@gmail.com ---
Hmm, I found this:

https://quickgit.kde.org/?p=plasma-workspace.git&a=commit&h=fbd4a876f32f402ae240450c4c7d8575391637b9

I'm not too familiar with it, as I don't use task manager applets (I use plank,
which matches apps to .desktop launchers for icon grabbing). But it seems to
implement the "Unity strategy" for tasks in the panel. If it makes sense to use
the good quality themed icons at regular sizes in the panel (and it does),
doesn't it also make sense to use the good quality themed icons at regular
sizes in the icon-based task switchers?

[Thomas Lübking via KDE Bugzilla]

Dette indlæg kan være upassende. Klik for at få det vist.

[Martin Gräßlin via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #9 from Martin Gräßlin <***@kde.org> ---
GTK+ has a way to link the desktop file to a window. In Qt 5.7 we will have a
way to provide the desktop file name in the QGuiApplication (see
https://doc-snapshots.qt.io/qt5-dev/qguiapplication.html#desktopFileName-prop
). The next frameworks release will already make use of this in KAboutData (see
commits.kde.org/kcoreaddons/c0313039170d751c61a44a8f97e199b7ed8ffa4f ). One can
specify the desktop file name and also through a command line argument.

Given that we have a way forward:
* get a common standard for reading the desktop file name for a window
* add support for that in Qt's xcb plugin
* add support for it in KWin
* take the icon from the desktop file if available
* patch all desktop files in our software to pass the desktop file name to the
application

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #10 from ***@gmail.com ---
Created attachment 95297
--> https://bugs.kde.org/attachment.cgi?id=95297&action=edit
Another sloppy task switcher

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #11 from ***@gmail.com ---
(In reply to Thomas Lübking from comment #8)

Post by Thomas Lübking via KDE Bugzilla
No, the *correct* strategy is to "link" the icon on the window.
(If I was soem downstream under full control of every sipped binary, I would
likely patch them in such way)
This was probably never considered by any standard because it only works
with local clients (for remote clients the icon pixmap must be transfered to
the X11 server, either as pixmap (old standard) or as encoded property
(typically used up to 128px) - both ways btw. allow for

I'm not sure what you mean, it looks like you didn't finish the thought. But
are you suggesting that a desktop icon theme should be applied at compile time
(and therefore that a user should recompile every application each time they
switch the icon theme)?

Post by Thomas Lübking via KDE Bugzilla
In addition: this is completely off topic. This bug is about icons not being
up-, but not downscaled (what sounds like a bug in the switcher only)
If you want to continue the discussion, please either open a new bug (though
we're likely not gonna use BAMF) or attend the mailing list (kwin æt kde døt
org)

I am having the exact problem reported by the reporter, as far as I can tell. I
have attached a screenshot.

[Thomas Lübking via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #12 from Thomas Lübking <***@gmail.com> ---
(In reply to andydecleyre from comment #11)

Post by via KDE Bugzilla
I'm not sure what you mean

"arbitrary sizes" - sorry, got deviated.

Post by via KDE Bugzilla
are you suggesting that a desktop icon theme should be applied at compile
time

good god: no (that idea is insane) - but the distros can just "fix"
applications that only set small icons downstream by setting larger variants as
well - this is ideally down at runtime and invoking the theme, though some
applications indeed use hardcoded icons (and that could be fixed as well). Or
the applications just fox themselves upstream, the standards aren't exactly
new...

Post by via KDE Bugzilla
I am having the exact problem reported by the reporter, as far as I can
tell. I have attached a screenshot.

The bug is that icons are scaled up, what (afaik) was not intended (resp. the
behavior explicitly changed at some point), not that some clients provide
insufficient icons.

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #13 from ***@gmail.com ---
(In reply to Thomas Lübking from comment #12)

Post by Thomas Lübking via KDE Bugzilla
good god: no (that idea is insane) - but the distros can just "fix"
applications that only set small icons downstream by setting larger variants
as well - this is ideally down at runtime and invoking the theme, though
some applications indeed use hardcoded icons (and that could be fixed as
well).

Do you have any pointers for further reading/instructions on this? I'd like to
fix all apps on my system to better accommodate KDE's icon behavior.

[Thomas Lübking via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #14 from Thomas Lübking <***@gmail.com> ---
You'd have to download the firefox sources and patch them to include higher res
icons in _NET_WM_ICON - same goes for all other problematic clients.
How to patch firefox and others, you'll have to ask the resp. maintainers. I've
never taken a deep look into the FF source code.

That said, *my* firefox (41.0.2, archlinux) has up to 128px icons there (check
"xprop" on the window) - so it seems not broken at all. Maybe your icon theme
has simply no bigger variant for it?

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #15 from ***@gmail.com ---
(In reply to Thomas Lübking from comment #14)

Post by Thomas Lübking via KDE Bugzilla
You'd have to download the firefox sources and patch them to include higher
res icons in _NET_WM_ICON - same goes for all other problematic clients.

I don't understand -- if the icon comes from whichever icon theme I happen to
be using, how is this not recompiling firefox every time I switch icon themes?

Post by Thomas Lübking via KDE Bugzilla
That said, *my* firefox (41.0.2, archlinux) has up to 128px icons there
(check "xprop" on the window) - so it seems not broken at all. Maybe your
icon theme has simply no bigger variant for it?

My icon theme is strictly composed of scalable svgs, and a higher resolution
version appears without problem in plank. Here's what xprop says about the

Post by Thomas Lübking via KDE Bugzilla
_NET_WM_ICON_GEOMETRY(CARDINAL) = 1680, 266, 0, 0

[Thomas Lübking via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #16 from Thomas Lübking <***@gmail.com> ---
Because the icons are not compiled into the application.
Firefox loads the image from disk, encodes it into a bytearray and uploads that
to the X11 server as either a pixmap or a window property.
I don't know though, whether (your) firefox can handle svg icons.

_NET_WM_ICON_GEOMETRY is *not* _NET_WM_ICON and not nearly related (it
indicates where the window iconifies, ie "minimizes")
You should get some ascii-art representation (and size hints) when running
"xprop _NET_WM_ICON" on the window. If it's empty, the firefox client doesn't
set any netwm icon (but likely just an X11 resource hint (with the small icon)

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #17 from ***@gmail.com ---
I still don't know what to do about this issue or even how to correctly ask
about it, but anyway "xprop _NET_WM_ICON" applied to my firefox-beta window
yields an ascii rendering and:

"_NET_WM_ICON(CARDINAL) = Icon (48 x 48):"

The same command on Konversation (which the task switcher also displays in a
hideous fashion):

"_NET_WM_ICON: not found."

For mpv: renderings for 16, 32 and 64, but not from the theme.

Telegram Desktop: "_NET_WM_ICON(CARDINAL) = " and task switcher does not use
icon from the theme.

Sublime Text 2: 16, 32, 48, 128, and none are from the theme

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #18 from ***@gmail.com ---
I'd also like to note that the icons shown by the "Switch Window" "Mouse
Action" for the desktop are all correct. The sizes are small, so I can't
confirm that whatever method used there would work perfectly at larger sizes,
but they are all from the current theme, which is an enormous improvement over
the mish-mash of the task switcher.

Can we not just use the same rules the Switch Window Mouse Action uses?

I'll try to find out how that one works.

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #19 from ***@gmail.com ---
My investigation led me here:
https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/master/entry/plasma-workspace/containmentactions/switchwindow/switch.cpp

Which features:

Plasma::DataEngine::Data window = tasks->query(source);
and
action->setIcon(window.value("icon").value<QIcon>());

I don't know what's really going on here though.

[Thomas Lübking via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #20 from Thomas Lübking <***@gmail.com> ---
re-read comment #8 and comment #9

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #21 from ***@gmail.com ---
Ok, thank you, so I did (for the second time today). I did not find an
explanation of how switchwindow finds icons.

[Thomas Lübking via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #22 from Thomas Lübking <***@gmail.com> ---
"Unlike the WM, the taskbar has an additional knowledge here because a desktop
service (launcher item for the "pinned" program) typically also references the
application icon (the information that the clients need to wire up to the WM,
see "correct strategy")"

The windowmenu draws from this information and to make that clear: it's a bug
to heuristically work around other bugs (some clients settign the "wrong" icon)
and kills the option to adjust the icon at runtime.

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #23 from ***@gmail.com ---
I thought you were saying that works for pinned programs/taskbars, because
those are already associated with the .desktop launchers. The switchwindow has
no such "pinning" and I have no taskbar, so I don't see how it gets connected
to the launchers.

From a user's perspective, the icon matching for switchwindow works perfectly
and the icon matching for task switcher works horribly.

The functional way is already code that's part of the project.

I accept that technically the functional way is not ideal for you, but I don't
deeply understand. In your ideal way, would you have to restart each
application after changing the icon theme, each time? Do you know how to fix
the cases like Sublime Text 2, where the icon is sized well, but not from the
theme?

Anyway, it seems to me that between these two methods, both are broken, but
only one appears broken to the user, and therefore the one that functions
perfectly on the user-facing level should be preferred. Isn't the point a good
user experience?

[Thomas Lübking via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #24 from Thomas Lübking <***@gmail.com> ---
(In reply to andydecleyre from comment #23)

Post by via KDE Bugzilla
I thought you were saying that works for pinned programs/taskbars, because
those are already associated with the .desktop launchers. The switchwindow

Uses exactly the same source as the taskbar.

Post by via KDE Bugzilla
The functional way is already code that's part of the project.

plasmashell != kwin - it would be kinda sick to load the entire application
database into the window manager because some clients set unwanted icons (and
then prefer the static icon over the actual one)

Post by via KDE Bugzilla
In your ideal way, would you have to restart each application after changing the icon theme,

No, the client updates its icons (when it receives such trigger) and exports
that information on the window.
And restarting won't help - the problem is that eg. firefox loads its icon from
the hicolor theme unconditionally (though on your side it even seems to be from
/usr/lib/firefox/browser/chrome/icons/default ...) instead of respecting the
theme configured for the desktop.

Post by via KDE Bugzilla
perfectly on the user-facing level should be preferred

It's not.
What you demand is to prefer a static icon that is mentioned in a desktop
service that may or may not belong to this window over the icon that the client
explicitly chose.

A *possible* sane solution is to have the clients provide a link to their
desktop service (see comment #9) and *only* specify actual icons (on top) if
they want to replace that.

However, for clients that wish to provide overlays on their icons (eg. to
indicate the playing state or whatever) that's neither a solution and they will
just have to do the pretty straight forward thing to simply read the icon from
the theme that's configured for the present desktop.

[Diego-MX]

https://bugs.kde.org/show_bug.cgi?id=351055

Diego-MX <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #25 from Diego-MX <***@gmail.com> ---
I have this same issue with my KDE installation and I had initially felt lucky
for finding this thread that addresses it. However much of what is discussed
here goes way beyond my experience; and unfortunately, I couldn't understand
the part that discusses the solution, but instead read much about the problem
itself.

I'd like to ask for some specific steps on fixing, for example, Firefox icons.

Cheers.

[Martin Gräßlin]

https://bugs.kde.org/show_bug.cgi?id=351055

Post by Diego-MX
I'd like to ask for some specific steps on fixing, for example, Firefox icons.

This can only be fixed by Firefox by installing larger icons on their windows.
The version I use only installs a 48x48 icon and that's too small. We would
need icons of size 128x128 or better 512x512. That's something only Firefox can
do. So to get this fixed you would need to create a bug against Firefox.

[Marian]

https://bugs.kde.org/show_bug.cgi?id=351055

Marian <***@icloud.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@icloud.com

--- Comment #27 from Marian <***@icloud.com> ---
(In reply to Martin Gräßlin from comment #26)

Post by Martin Gräßlin

Post by Diego-MX
I'd like to ask for some specific steps on fixing, for example, Firefox icons.

This can only be fixed by Firefox by installing larger icons on their
windows. The version I use only installs a 48x48 icon and that's too small.
We would need icons of size 128x128 or better 512x512. That's something only
Firefox can do. So to get this fixed you would need to create a bug against
Firefox.

Where do I have to search for those icons to confirm? I can reproduce this
behaviour for so many applications. Take Vivaldi browser, it ships with a huge
variety of dimensions of their icon in .png format in /opt/vivaldi AND in
/usr/share/hicolor including sizes of 128 and 256 yet the large icon task
switcher totally ignores them and any other icon provided in hicolor or the
installed theme or pixmaps or /opt/vivaldi. Indeed xprop tells me that
_NET_WM_ICON(CARDINAL) = Icon (32 x 32)
Which to me looks like it's actually an issue with some programmed lines not so
much icon structures, but that really doesn't help me at all. This is so
annoying to even try to get a hint on where to start to report...

Another test case for me is Nylas Mail. I played around with their icons in
hicolor and pixmaps, replacing their original .png images with own ones. Now
the task switcher shows the logo icon for X11 and there is no xprop for
_NET_WM_ICON at all.

And here is another completely weird example: Encryptr (password storage app).
I can find a high resolution .png of their logo in /usr/share/pixmaps, no icons
in /opt/encryptr, no icons in hicolor and apparently it has scalable svgs in
the installed theme. Yet the large icon task switcher found a totally different
high resolution icon for the application which I don't even remotely know where
it could be stored since it's completely foreign to me and I have never seen it
before nor can I find it in my installed themes...Here xprop tells me that:
_NET_WM_ICON(CARDINAL) =
Yet it shows a high resolution icon which is not the default X11 icon.
Frustrating to debug...

[Martin Gräßlin]

https://bugs.kde.org/show_bug.cgi?id=351055

Post by Marian
Where do I have to search for those icons to confirm?

KWin takes the icon you can see in xprop. If there is only one in 32x32 that
one will be used. KWin does not use any installed icon as that is not how it's
supposed to be done for X11 window managers.

For Qt/KDE applications we are able to use the installed icons thanks to an
extension. Maybe it could be possible to define a window rule for the .desktop
file of a window.

[Marian]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #29 from Marian <***@icloud.com> ---
(In reply to Martin Gräßlin from comment #28)

Post by Martin Gräßlin

Post by Marian
Where do I have to search for those icons to confirm?

KWin takes the icon you can see in xprop. If there is only one in 32x32 that
one will be used. KWin does not use any installed icon as that is not how
it's supposed to be done for X11 window managers.
For Qt/KDE applications we are able to use the installed icons thanks to an
extension. Maybe it could be possible to define a window rule for the
.desktop file of a window.

Thanks for clarifying!

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=351055

Nate Graham <***@zoho.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@zoho.com

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #30 from Nate Graham <***@zoho.com> ---
Filed bugs for Firefox and Thunderbird:

https://bugzilla.mozilla.org/show_bug.cgi?id=1371932
https://bugzilla.mozilla.org/show_bug.cgi?id=1371931

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #31 from Nate Graham <***@zoho.com> ---
Created attachment 106379
--> https://bugs.kde.org/attachment.cgi?id=106379&action=edit
Task Switcher preview with high-res icons

Here's something weird: Firefox and Thunderbird use upscaled icons in the
*actual* Large Icons task switcher, but the *preview* correctly displays crisp
high-res icons! I've attached a screen recording that shows this.

So there is already code somewhere that knows how to find high-res icons. Not
sure why the SimpleScreenRecorder icon didn't show up in the preview, though.

[Martin Flöser]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #32 from Martin Flöser <***@kde.org> ---
The tasks applet has a different resolver. The difference is that tasks looks
for applications, but KWin looks for Windows and uses the icon the window
provides.

[Dr. Chapatin]

https://bugs.kde.org/show_bug.cgi?id=351055

Dr. Chapatin <***@gmx.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmx.com

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #33 from Nate Graham <***@zoho.com> ---
Perhaps we could use code that fetches the application icon when the Task
Switcher is set to show only one icon per application--making it an app
switcher instead of a window switcher.

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #34 from Nate Graham <***@zoho.com> ---
So if I'm understanding this correctly, the issue is that instead of using the
icon in the .desktop file (which almost always looks good), KWin asks the
window itself what icon to display, and a lot of programs just have poor logic
here and return bad icons, which is particularly visible with the Large Icons
style.

This is done for cases when the window might want to provide a
context-sensitive icon that's more relevant than the generic one in the
.desktop file.

Is that right?

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=351055

Nate Graham <***@zoho.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.kde.org/show_b
| |ug.cgi?id=380508

[Martin Flöser]

https://bugs.kde.org/show_bug.cgi?id=351055

Post by Nate Graham
Is that right?

Kind of. The window manager spec for icons says that one should use the icon
provided by the window through the properties. The window manager spec doesn't
know anything about desktop files and the icons provided there. We assume that
applications know best what icon to provide. This allows for example KMail to
show different icons for the main window and the composer window. Through
desktop file all windows are same. Or it is very common for chat applications
to include a "composing text" icon for the window icon.

If we go for desktop file we break all of that. Plus there is no standard for
it. One could say that the task manager is violating the cross desktop standard
by using the icons from the desktop file.

The important difference between the task manager and the window manager is
that the task manager cares about the tasks (that is applications) while the
window manager cares about the windows. So for alt+tab it is much more
important to show the icon the window provides than for the task manager which
might group all windows of one application.

In the end KWin needs to use what the window provides. If that sucks, it sucks.
But it's nothing the window manager can do about.

Now to my actual plans: I'm currently working on implementing window rules for
Wayland. As on Wayland the icons are only taken from the desktop file the
situation is different. Many applications fail to set the desktop file, so we
end up without any icon. To address this I want to introduce a new window rule
to set the desktop file. This can then also be used on X11 to force for bad
applications such as Firefox to take the icon from the desktop file instead of
the window.

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=351055

Nate Graham <***@zoho.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |CONFIRMED
Ever confirmed|0 |1

--- Comment #36 from Nate Graham <***@zoho.com> ---
It sounds like this will be essentially fixed in Wayland, since the icons in
desktop files are wrong or bad much less often than the icons specified by the
windows themselves (in my experience). Also that will eliminate discrepancies
between the icon in the Task Manager--which is usually themed--and the icon
shown in the Task Switcher--which is specified directly by the app and usually
bypasses theming.

There is one scenario today, pre-Wayland, where I can see the logic of
overriding the window-specified icon with the one in the .desktop file: when
using a Task Switcher with "Only one window per application" checked. With
this, you're basically signifying that you want the Task switcher to show
applications rather than windows, so I think it makes sense to show application
icons as specified in the application's desktop file.

But I'll wait patiently for the Wayland version to exclusively use icons from
the desktop file. :)

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=351055

Nate Graham <***@zoho.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugzilla.mozilla.or
| |g/show_bug.cgi?id=1371932

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=351055

Nate Graham <***@zoho.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugzilla.mozilla.or
| |g/show_bug.cgi?id=1371931

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=351055

Nate Graham <***@zoho.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.documentfounda
| |tion.org/show_bug.cgi?id=65
| |754

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=351055

Nate Graham <***@zoho.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://github.com/endless-
| |sky/endless-sky/issues/2645

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=351055

Nate Graham <***@zoho.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #37 from Nate Graham <***@zoho.com> ---
*** Bug 371677 has been marked as a duplicate of this bug. ***

[Simon Andric]

https://bugs.kde.org/show_bug.cgi?id=351055

Simon Andric <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=351055

Nate Graham <***@zoho.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Keywords| |usability

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=351055

Nate Graham <***@zoho.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@manki.in

--- Comment #38 from Nate Graham <***@zoho.com> ---
*** Bug 387874 has been marked as a duplicate of this bug. ***

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=351055

Nate Graham <***@zoho.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Summary|Icons are upscaled in |Icons are upscaled in
|"Large Icons" Task Switcher |"Large Icons" Task Switcher
| |because KWin gets icons
| |from the window rather than
| |the window's application's
| |desktop file

[b***@kde.org]

https://bugs.kde.org/show_bug.cgi?id=351055

***@gmail.com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #39 from ***@gmail.com ---
Another affected program:
https://github.com/CDrummond/cantata/issues/1206

[Dr. Chapatin]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #40 from Dr. Chapatin <***@gmx.com> ---
Created attachment 110637
--> https://bugs.kde.org/attachment.cgi?id=110637&action=edit
quod libet and smplayer

my screenshot shows quod libet player and smplayer.

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #41 from Nate Graham <***@zoho.com> ---
Right, many apps look bad in the Large Icons Task Switcher because of this
issue.

One of three things needs to happen:
1. Martin changes KWin to use the icons from the desktop file rather than
asking the app for its window icon
2. You use KWin under Wayland
3. You submit bug reports or patches for all affected apps

[Dr. Chapatin]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #42 from Dr. Chapatin <***@gmx.com> ---
I prefer Wayland alternative.
But it's unusable yet.
Today I updated Arch to plasma 5.12.1 and qt 5.10 and now whole session is
crashing when I press alt+tab.
Also it's impossible to type accents using my kayboard layout (qt bug).

[Dr. Chapatin]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #43 from Dr. Chapatin <***@gmx.com> ---
Sorry, I meant qt 5.10.1.

[Dr. Chapatin]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #44 from Dr. Chapatin <***@gmx.com> ---
Many apps are affected.

Loading Image...

[Andras Soltesz]

https://bugs.kde.org/show_bug.cgi?id=351055

Andras Soltesz <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #45 from Andras Soltesz <***@gmail.com> ---
This affects me badly since I use Firefox, Thunderbird and some Java
applications on KDE Neon with Xorg. All of them have low resolution images
(especially the Java apps, only IDEA provides a proper image).

The solution mentioned by Martin in Comment 35 would be adequate for me, I
would simply rule-match my misbehaving apps with their .desktop files to have a
nice, high res image.

@Martin
Is there some idea when that new rule type could make it to kwin?

BTW: As always, thanks for the great work, I am an avid user of Plasma 5.

[Martin Flöser]

https://bugs.kde.org/show_bug.cgi?id=351055

Post by Andras Soltesz
@Martin
Is there some idea when that new rule type could make it to kwin?

it's the next item on my todo list for coding unless a bug comes in. So if
everything goes well: maybe this weekend.

[Martin Flöser]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #47 from Martin Flöser <***@kde.org> ---
Git commit d61eaa2d66b0749d6b03bfd1d6c6a93751187a84 by Martin Flöser.
Committed on 18/03/2018 at 08:15.
Pushed by graesslin into branch 'master'.

Add a new desktopfile name rule

Summary:
This allows to override the desktop file name.

Test Plan: Created a window rule for telegram-desktop to fix the icon

Reviewers: #kwin, #plasma

Subscribers: kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D11266

M +3 -1 abstract_client.cpp
M +1 -1 abstract_client.h
M +29 -0 autotests/integration/shell_client_rules_test.cpp
M +1 -0 dbusinterface.cpp
M +6 -0 kcmkwin/kwinrules/ruleswidget.cpp
M +1 -0 kcmkwin/kwinrules/ruleswidget.h
M +65 -5 kcmkwin/kwinrules/ruleswidgetbase.ui
M +1 -1 manage.cpp
M +13 -1 rules.cpp
M +5 -1 rules.h
M +1 -1 shell_client.cpp

https://commits.kde.org/kwin/d61eaa2d66b0749d6b03bfd1d6c6a93751187a84

[Szymon]

https://bugs.kde.org/show_bug.cgi?id=351055

Szymon <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #48 from Szymon <***@gmail.com> ---
Hi, i found new icons to fix, PhpStorm (probably all Jet Brains Apps) and
Gravit Designer . And some WINE apps . It's only one problem icon isn't changed
by .desktop file. On task bar working good as well but on Task Switcher apps
have old / small pix elated icon. I try all possible ways to change that icons
without success. Funny cuz on Gnome DE my .desktop file working good. Tested
on Xorg / KWayland.

[Szymon]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #49 from Szymon <***@gmail.com> ---
Window Rule don't work for Nvidia Settings / Gravit Designer.

[Szymon]

https://bugs.kde.org/show_bug.cgi?id=351055

Szymon <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|CONFIRMED |RESOLVED
Resolution|--- |INVALID

--- Comment #50 from Szymon <***@gmail.com> ---
I managed to fix this error. But this is rather a mistake of my configuration.
I was guided by the name of the .desktop shortcut from the Application Menu
(Edit). However, I went to the path of the. Font file and it was named without
space. It just worked, I'm sorry for unnecessary comments. Everything works as
it should.

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=351055

Nate Graham <***@kde.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |---

--- Comment #51 from Nate Graham <***@kde.org> ---
Please don't close a bug just because you've found a workaround that works for
you. This bug tracks the issue itself as it applies to everyone, not to you and
your personal workaround.

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=351055

Nate Graham <***@kde.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |CONFIRMED

[Dr. Chapatin]

https://bugs.kde.org/show_bug.cgi?id=351055

--- Comment #52 from Dr. Chapatin <***@gmx.com> ---
Still valid for plasma 5.14 beta on Arch Linux.