Bug 351055 - In Task Switchers, show icons from icon theme rather than from window metadata, to prevent icons from looking blurry, ugly, and/or inconsistent (especially noticeable in "Large Icons" Task Switcher)
Summary: In Task Switchers, show icons from icon theme rather than from window metadat...
Status: RESOLVED NOT A BUG
Alias: None
Product: kwin
Classification: Plasma
Component: tabbox (show other bugs)
Version: 5.3.1
Platform: Kubuntu Linux
: HI wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL: http://pasteboard.co/2xqvubnV.png
Keywords: usability
: 371677 410676 422253 445060 447300 461879 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-08-07 10:09 UTC by Vincenzo
Modified: 2023-02-06 14:32 UTC (History)
20 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Another sloppy task switcher (35.56 KB, image/png)
2015-11-03 20:14 UTC, andydecleyre
Details
Task Switcher preview with high-res icons (2.10 MB, video/webm)
2017-06-30 01:34 UTC, Nate Graham
Details
quod libet and smplayer (24.43 KB, image/png)
2018-02-13 22:02 UTC, Patrick Silva
Details
dozens of window rules on Plasma 5.18.1 (3.05 MB, video/webm)
2020-02-20 13:23 UTC, Patrick Silva
Details
Task Switcher fails to synchronize icons with Task Manager (597.31 KB, image/png)
2021-07-14 21:24 UTC, ratijas
Details
They don't match (311.86 KB, image/jpeg)
2023-02-03 19:53 UTC, Nate Graham
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vincenzo 2015-08-07 10:09:35 UTC
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
Comment 1 Thomas Lübking 2015-08-07 10:45:23 UTC
please attach the full output of "xprop" on such window.
though afair in case of lacking big icons, small ones were *not* supposed to be upscaled.

---
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
Comment 2 Vincenzo 2015-08-07 11:25:15 UTC
$ 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
Comment 3 Thomas Lübking 2015-08-07 11:30:54 UTC
Sorry, but I  meant not of the tabbox, but of such window which is represented by a "blurry" (scaled) icon.
Comment 4 Vincenzo 2015-08-07 11:35:21 UTC
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 - ---@gmail.com - Gmail - Google Chrome"
_NET_WM_NAME(UTF8_STRING) = "[kwin] [Bug 351055] Icons are fuzzy (low resolution) in Task Switcher with Large Icons - ---@gmail.com - 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
Comment 5 Thomas Lübking 2015-08-07 12:02:48 UTC
Thanks.
Together with bug #350645 it seems icons are now up-, but no longer downscaled (ie. the exact opposite of what was intended)
Comment 6 andydecleyre 2015-11-02 20:12:41 UTC
(In reply to Thomas Lübking from comment #1)
> 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.
Comment 7 andydecleyre 2015-11-02 20:18:57 UTC
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?
Comment 8 Thomas Lübking 2015-11-02 21:00:48 UTC
(In reply to andydecleyre from comment #6)
> (In reply to Thomas Lübking from comment #1)
> > 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?
No, patch was https://git.reviewboard.kde.org/r/108957/

> me, an idiot
That doesn't work the way you may hope.

> to be the obviously correct strategy.
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 

> 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?

Because
a) we do not know which icon belongs to what window unless the client tells us.

As pointed out, BAMF is one giant *ugly* hack that relies on string mapping to deduce the icon from some attributes like the window class. This may work (to some degree) downstream, but starts to fail when binaries are installed with a different name ("Heck", some java clients change their class depending on the used JDK, firefox for a while changed the window class with *every* release (to some internal codename) - so we'd just get bug reports "foobar uses wrong icon", then we "fix" it and "foobar" is meanwhile called "barfoo" - and distro blablubb btw. calls it "gnarf" - is is an unmaintainable mess where we run after random changes of other upstream as well as downstream.

b) the client may actually not want to use the application icon for the window (but eg. a webpage icon in case of browsers, an additional overlay to eg. hint the playing state in case of media players ...)

(In reply to andydecleyre from comment #7)
> Hmm, I found this:
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")

tl;dr:
The "correct" fix for this is to have the clients hint hi-res icons on windows. It is the *only* correct fix. Anything else is a hack. Also again: they /can/ - some are simply broken. That's all.

KWindowSystem (lib code) therefore cannot start guessing the icon, KWin (client code) probably could, but the result *will* be glitchy (and likely cause quite a lot of bug reports because client abc isn't resolved - we'd best introduce a kconfig system or add a rule so that downstream/the user can add/override mappings)


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)
Comment 9 Martin Flöser 2015-11-03 07:27:10 UTC
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
Comment 10 andydecleyre 2015-11-03 20:14:10 UTC
Created attachment 95297 [details]
Another sloppy task switcher
Comment 11 andydecleyre 2015-11-03 20:14:30 UTC
(In reply to Thomas Lübking from comment #8)
> 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)?

> 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.
Comment 12 Thomas Lübking 2015-11-03 20:23:29 UTC
(In reply to andydecleyre from comment #11)

> I'm not sure what you mean
"arbitrary sizes" - sorry, got deviated.

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

> 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.
Comment 13 andydecleyre 2015-11-03 21:00:23 UTC
(In reply to Thomas Lübking from comment #12)
> 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.
Comment 14 Thomas Lübking 2015-11-03 21:20:58 UTC
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?
Comment 15 andydecleyre 2015-11-03 21:35:06 UTC
(In reply to Thomas Lübking from comment #14)
> 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?

> 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 window icon:

> _NET_WM_ICON_GEOMETRY(CARDINAL) = 1680, 266, 0, 0
Comment 16 Thomas Lübking 2015-11-03 21:54:11 UTC
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)
Comment 17 andydecleyre 2016-02-03 23:00:55 UTC
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
Comment 18 andydecleyre 2016-02-03 23:10:19 UTC
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.
Comment 19 andydecleyre 2016-02-03 23:27:33 UTC
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.
Comment 20 Thomas Lübking 2016-02-03 23:59:24 UTC
re-read comment #8 and comment #9
Comment 21 andydecleyre 2016-02-04 00:43:10 UTC
Ok, thank you, so I did (for the second time today). I did not find an explanation of how switchwindow finds icons.
Comment 22 Thomas Lübking 2016-02-04 00:49:25 UTC
"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.
Comment 23 andydecleyre 2016-02-04 17:49:08 UTC
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?
Comment 24 Thomas Lübking 2016-02-04 18:37:20 UTC
(In reply to andydecleyre from comment #23)
> 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.

> 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)

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

> 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.
Comment 25 Diego-MX 2016-11-14 05:13:41 UTC
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.
Comment 26 Martin Flöser 2016-11-14 09:01:21 UTC
> 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.
Comment 27 Marian Arlt 2017-05-05 19:00:30 UTC
(In reply to Martin Gräßlin from comment #26)
> > 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...
Comment 28 Martin Flöser 2017-05-05 19:29:21 UTC
> 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.
Comment 29 Marian Arlt 2017-05-05 19:30:58 UTC
(In reply to Martin Gräßlin from comment #28)
> > 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!
Comment 30 Nate Graham 2017-06-10 13:50:48 UTC
Filed bugs for Firefox and Thunderbird:

https://bugzilla.mozilla.org/show_bug.cgi?id=1371932
https://bugzilla.mozilla.org/show_bug.cgi?id=1371931
Comment 31 Nate Graham 2017-06-30 01:34:51 UTC
Created attachment 106379 [details]
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.
Comment 32 Martin Flöser 2017-06-30 04:20:45 UTC
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.
Comment 33 Nate Graham 2017-07-01 21:25:42 UTC
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.
Comment 34 Nate Graham 2017-10-15 04:55:54 UTC
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?
Comment 35 Martin Flöser 2017-10-15 07:36:31 UTC
> 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.
Comment 36 Nate Graham 2017-10-15 21:42:15 UTC
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. :)
Comment 37 Nate Graham 2017-10-16 00:09:02 UTC
*** Bug 371677 has been marked as a duplicate of this bug. ***
Comment 38 Nate Graham 2017-12-13 18:01:39 UTC
*** Bug 387874 has been marked as a duplicate of this bug. ***
Comment 39 pmargeti34 2018-02-13 10:35:18 UTC
Another affected program:
https://github.com/CDrummond/cantata/issues/1206
Comment 40 Patrick Silva 2018-02-13 22:02:22 UTC
Created attachment 110637 [details]
quod libet and smplayer

my screenshot shows quod libet player and smplayer.
Comment 41 Nate Graham 2018-02-13 22:04:28 UTC
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
Comment 42 Patrick Silva 2018-02-13 22:10:58 UTC
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).
Comment 43 Patrick Silva 2018-02-13 22:12:19 UTC
Sorry, I meant qt 5.10.1.
Comment 44 Patrick Silva 2018-02-23 16:45:13 UTC
Many apps are affected.

https://images2.imgbox.com/b8/4f/dXpyXFgv_o.gif
Comment 45 Andras Soltesz 2018-03-09 12:51:40 UTC
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.
Comment 46 Martin Flöser 2018-03-09 17:17:13 UTC
> @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.
Comment 47 Martin Flöser 2018-03-18 08:16:28 UTC
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
Comment 48 Szymon 2018-06-19 19:21:41 UTC
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.
Comment 49 Szymon 2018-06-21 15:46:59 UTC
Window Rule don't work for Nvidia Settings / Gravit Designer.
Comment 50 Szymon 2018-06-26 12:47:41 UTC
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.
Comment 51 Nate Graham 2018-06-26 12:49:40 UTC
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.
Comment 52 Patrick Silva 2018-09-14 15:02:49 UTC
Still valid for plasma 5.14 beta on Arch Linux.
Comment 53 Patrick Silva 2019-05-17 20:31:26 UTC
This bug persits on Plasma 5.16 beta.

Operating System: Arch Linux 
KDE Plasma Version: 5.15.90
KDE Frameworks Version: 5.58.0
Qt Version: 5.13.0 beta3
Comment 54 Nate Graham 2019-05-18 02:45:30 UTC
On X11, the bug won't be solved all at once; it needs to be fixed for every app.
Comment 55 Nate Graham 2019-08-07 19:44:03 UTC
*** Bug 410676 has been marked as a duplicate of this bug. ***
Comment 56 Patrick Silva 2020-02-20 13:17:55 UTC
Any news on this issue?

Depending on running apps, using Large Icons task switcher on Plasma 5.18.1 is still a very bad experience.
Very few app provides correct/good icon to kwin, resulting in many blurry/pixelated icons and/or icons that do not match with the icon shown by the same app in task manager. Many apps show the generic X11 icon
in Large Icons task switcher instead of its own icon. See the following screen recording please.

https://www.youtube.com/watch?v=bJCcnt0-MwU

Operating System: Arch Linux 
KDE Plasma Version: 5.18.1
KDE Frameworks Version: 5.67.0
Qt Version: 5.14.1
Comment 57 Patrick Silva 2020-02-20 13:23:15 UTC
Created attachment 126208 [details]
dozens of window rules on Plasma 5.18.1

As we can see in the attached screen recording, I had to create dozens of window rules to get rid of all the blurry/pixelated/wrong icons shown by Large Icons task switcher.
Comment 58 Nate Graham 2020-02-22 16:30:36 UTC
Gross, that's pretty awful.

KWin folks, is this really the best we can do? I mean, worst-case scenario, we could ship those rules by default, but it seems like there must be a better solution here.
Comment 59 Cristian Contescu 2020-05-31 10:47:43 UTC
(In reply to Patrick Silva from comment #57)
> Created attachment 126208 [details]
> dozens of window rules on Plasma 5.18.1
> 
> As we can see in the attached screen recording, I had to create dozens of
> window rules to get rid of all the blurry/pixelated/wrong icons shown by
> Large Icons task switcher.

And what exactly were the rules you have added contained? As I am interested in doing so, at least for a few of the applications I am using daily (e.g.: tilix).
Comment 60 Patrick Silva 2020-05-31 11:22:56 UTC
(In reply to Cristian Contescu from comment #59)
> (In reply to Patrick Silva from comment #57)
> > Created attachment 126208 [details]
> > dozens of window rules on Plasma 5.18.1
> > 
> > As we can see in the attached screen recording, I had to create dozens of
> > window rules to get rid of all the blurry/pixelated/wrong icons shown by
> > Large Icons task switcher.
> 
> And what exactly were the rules you have added contained? As I am interested
> in doing so, at least for a few of the applications I am using daily (e.g.:
> tilix).

You have to set the .desktop file name in "Appearance & fixes" tab.
Comment 61 Cristian Contescu 2020-05-31 11:39:09 UTC
(In reply to Patrick Silva from comment #60)
> (In reply to Cristian Contescu from comment #59)
> > (In reply to Patrick Silva from comment #57)
> > > Created attachment 126208 [details]
> > > dozens of window rules on Plasma 5.18.1
> > > 
> > > As we can see in the attached screen recording, I had to create dozens of
> > > window rules to get rid of all the blurry/pixelated/wrong icons shown by
> > > Large Icons task switcher.
> > 
> > And what exactly were the rules you have added contained? As I am interested
> > in doing so, at least for a few of the applications I am using daily (e.g.:
> > tilix).
> 
> You have to set the .desktop file name in "Appearance & fixes" tab.

Wow, this is a game changer. Thank you very much for the trick. By just pointing the desktop file to the original desktop file:
/usr/share/applications/com.gexperts.Tilix.desktop

I get a nice looking icon in the "Large Icons" task switcher. Can't this be set somehow globally?
Comment 62 Nate Graham 2020-06-01 02:35:45 UTC
*** Bug 422253 has been marked as a duplicate of this bug. ***
Comment 63 Nate Graham 2020-06-01 14:07:53 UTC
*** Bug 422253 has been marked as a duplicate of this bug. ***
Comment 64 Nate Graham 2020-10-26 19:53:27 UTC
(In reply to Cristian Contescu from comment #61)
> Wow, this is a game changer. Thank you very much for the trick. By just
> pointing the desktop file to the original desktop file:
> /usr/share/applications/com.gexperts.Tilix.desktop
> 
> I get a nice looking icon in the "Large Icons" task switcher. Can't this be
> set somehow globally?
I would like that too.
Comment 65 ratijas 2021-07-14 21:24:49 UTC
Created attachment 140062 [details]
Task Switcher fails to synchronize icons with Task Manager

Still suffering from it. Installed candy-icon theme long ago. Most KDE apps got the replacements, but some third-party apps, including Sublime Text & Merge, Inkscape, Qt Creator, Intellij products installed via JetBrains Toolbox, Discord etc. -- they just can't get replaced icons in Task Switcher without manual configuration on a per-application basis.
Comment 66 Nate Graham 2021-11-08 21:37:03 UTC
*** Bug 445060 has been marked as a duplicate of this bug. ***
Comment 67 Nate Graham 2022-01-11 21:54:21 UTC
*** Bug 447300 has been marked as a duplicate of this bug. ***
Comment 68 joeytwiddle 2022-08-20 02:55:40 UTC
For end-users who want to get hi-res icons in their Task Switcher today, I have provided some simple instructions here:

https://askubuntu.com/a/1403918/133393
Comment 69 Nate Graham 2022-11-18 15:55:53 UTC
*** Bug 461879 has been marked as a duplicate of this bug. ***
Comment 70 David Edmundson 2023-02-03 15:52:48 UTC
If clients are providing wrong metadata, this is on the clients to fix. Please report to the relevant clients.
Comment 71 Nate Graham 2023-02-03 18:49:27 UTC
I'm not sure it's reasonable to expect the rest of the world to get fixed, especially when this is so widespread an issue among 3rd-party apps. There is an alternative: have KWin display themed app icons in Task Switchers, rather than using the icons provided by the windows themselves. This would also fix a source of visual incompatibility between the icons shown by the KWin-provided Task Switcher and the Plasma-provided Task Manager. Re-titling the bug to make it clear that this is a wishlist change proposal.
Comment 72 David Edmundson 2023-02-03 19:48:16 UTC
>There is an alternative: have KWin display themed app icons in Task Switchers, 

It does already.
Comment 73 Nate Graham 2023-02-03 19:53:32 UTC
Created attachment 155930 [details]
They don't match

Then what am I looking at here? This is on Wayland, BTW.
Comment 74 Vlad Zahorodnii 2023-02-06 09:09:49 UTC
libtaskmanager relies on its heuristics.

kwin relies on specified app id. In case of gimp, it specifies neither _GTK_APPLICATION_ID nor _KDE_NET_WM_DESKTOP_FILE, so kwin falls back to _NET_WM_ICON
Comment 75 frederic.parrenin@univ-grenoble-alpes.fr 2023-02-06 12:32:08 UTC
Dear all, I don't want to add confusion to this issue, but just give my opinion as a user.
I agree with @Nate that it is somewhat confusing to have different icons for the Kwin task switcher and the Plasma taskbar.
But I agree with others that the app-provided icon should be used and that apps can fix it if it has issues.
So instead of modifying Kwin, my proposition would be to modify the Plasma taskbar.
Different icons for an app (e.g., gimp) could be regrouped under the .desktop icon of the app in the taskbar.
But hovering onto the .desktop icon of the taskbar, the various windows of the app could appear with their app-id icon super-imposed.
This way, we would have the best of both worlds, with app-id icons still used but connected to the .desktop icons.
Let me know if you think it would be an acceptable solution or if it would have issues.
Comment 76 Nate Graham 2023-02-06 14:32:03 UTC
So on Wayland, it works as long as the window provides a way to map it to its desktop file? Do I have that right?