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

$ 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

Sorry, but I  meant not of the tabbox, but of such window which is represented by a "blurry" (scaled) icon.

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

Thanks.
Together with bug #350645 it seems icons are now up-, but no longer downscaled (ie. the exact opposite of what was intended)

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

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?

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

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

Created attachment 95297 [details]
Another sloppy task switcher

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

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

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

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?

(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

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)

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

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.

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.

re-read comment #8 and comment #9

Ok, thank you, so I did (for the second time today). I did not find an explanation of how switchwindow finds icons.

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

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?

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

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.

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

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

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

(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!

Filed bugs for Firefox and Thunderbird:

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

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.

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.

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.

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?

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

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

*** Bug 371677 has been marked as a duplicate of this bug. ***

*** Bug 387874 has been marked as a duplicate of this bug. ***

Another affected program:
https://github.com/CDrummond/cantata/issues/1206

Created attachment 110637 [details]
quod libet and smplayer

my screenshot shows quod libet player and smplayer.

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

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

Sorry, I meant qt 5.10.1.

Many apps are affected.

https://images2.imgbox.com/b8/4f/dXpyXFgv_o.gif

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

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

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.

Window Rule don't work for Nvidia Settings / Gravit Designer.

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.

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.

Still valid for plasma 5.14 beta on Arch Linux.

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

On X11, the bug won't be solved all at once; it needs to be fixed for every app.

*** Bug 410676 has been marked as a duplicate of this bug. ***

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

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.

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.

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

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

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

*** Bug 422253 has been marked as a duplicate of this bug. ***

*** Bug 422253 has been marked as a duplicate of this bug. ***

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

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.

*** Bug 445060 has been marked as a duplicate of this bug. ***

*** Bug 447300 has been marked as a duplicate of this bug. ***

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

*** Bug 461879 has been marked as a duplicate of this bug. ***

If clients are providing wrong metadata, this is on the clients to fix. Please report to the relevant clients.

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.

>There is an alternative: have KWin display themed app icons in Task Switchers, 

It does already.

Created attachment 155930 [details]
They don't match

Then what am I looking at here? This is on Wayland, BTW.

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

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.

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?