> > Well, somewhere around the getIcon () code something's definitely wrong ->
> see
> > bug #1173916 and bug #1173694.
>
> I'm confused by what you mean by this.
>
Well, I just meant our switchers should act more intelligent and use the best-quality icons available, not low-res ones.
> Using the svg icon data from the current desktop icon theme is a very large
> undertaking, and is often quite a messy procedure because the process used to
> match applications to windows is at best inexact on the EWMH standard. This is
> the entire reason why lp:bamf exists.
>
Ah -> this explains why the Unity Switcher is doing this thing right (had no time to look at the code yet).
We should, in this case, check if bamf is available and mimic the icon selection behaviour of the Unity Switcher in all other Compiz Switchers then...
> As for the icons themselves, the EWMH says that the applications can specify
> an arbitrary array of arbitrarily sized icons in their window properties[1].
> It is up to the application to specify a high resolution icon. Note that the
> application is actually specifying the raw bitmap data that makes up the icon
> in each item of the array of icon properties as opposed to a filename.
>
A very interesting document. Will study that in detail later.
> The parameters to getIcon () specify the _maximum_ allowed icon dimensions
> (both width and height) to be used. So, for example if an application uploads
> icons sizes 32x32, 64x64, 128x128, 256x256 and 512x512 and we call getIcon
> with (240), then it will pick the largest icon below that size, that being the
> 128x128 icon size.
>
I could not find the problem in getIcon (), so my guess was it is "somewhere around that code"...
> Calling getIcon () with a certain parameter doesn't guarantee that you'll get
> an icon that size, but it does guarantee that you won't get an icon larger
> than it.
>
Ok.
> In any case, setting maximum of 512 should more than cover any icon size
> bottlenecks on the compiz side - its just up to the individual applications to
> provide larger icons.
>
> [1] http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html
I agree.
Nevertheless the Compiz Switchers should be tuned to be able to deliver high quality icons like the Unity Switcher already does...
> > Well, somewhere around the getIcon () code something's definitely wrong ->
> see
> > bug #1173916 and bug #1173694.
>
> I'm confused by what you mean by this.
>
Well, I just meant our switchers should act more intelligent and use the best-quality icons available, not low-res ones.
> Using the svg icon data from the current desktop icon theme is a very large
> undertaking, and is often quite a messy procedure because the process used to
> match applications to windows is at best inexact on the EWMH standard. This is
> the entire reason why lp:bamf exists.
>
Ah -> this explains why the Unity Switcher is doing this thing right (had no time to look at the code yet).
We should, in this case, check if bamf is available and mimic the icon selection behaviour of the Unity Switcher in all other Compiz Switchers then...
> As for the icons themselves, the EWMH says that the applications can specify
> an arbitrary array of arbitrarily sized icons in their window properties[1].
> It is up to the application to specify a high resolution icon. Note that the
> application is actually specifying the raw bitmap data that makes up the icon
> in each item of the array of icon properties as opposed to a filename.
>
A very interesting document. Will study that in detail later.
> The parameters to getIcon () specify the _maximum_ allowed icon dimensions
> (both width and height) to be used. So, for example if an application uploads
> icons sizes 32x32, 64x64, 128x128, 256x256 and 512x512 and we call getIcon
> with (240), then it will pick the largest icon below that size, that being the
> 128x128 icon size.
>
I could not find the problem in getIcon (), so my guess was it is "somewhere around that code"...
> Calling getIcon () with a certain parameter doesn't guarantee that you'll get
> an icon that size, but it does guarantee that you won't get an icon larger
> than it.
>
Ok.
> In any case, setting maximum of 512 should more than cover any icon size standards. freedesktop. org/wm- spec/1. 3/ar01s05. html
> bottlenecks on the compiz side - its just up to the individual applications to
> provide larger icons.
>
> [1] http://
I agree.
Nevertheless the Compiz Switchers should be tuned to be able to deliver high quality icons like the Unity Switcher already does...