[PATCH 1/3] winemenubuilder: Icon heights/widths of 0 mean 256, for Vista icons.

[Damjan Jovanovic]

On Wed, Jan 12, 2011 at 7:36 AM, Ken Thomases <ken at codeweavers.com> wrote:
> On Jan 11, 2011, at 2:41 AM, Damjan Jovanovic wrote:
>
>> The 256x256 pixel icons are designed to be viewed in that size. They
>> can, and often do, contain a different picture to the smaller icons.
>> When you scale them down to a smaller size, they look bad. On MacOS
>> that may not matter since multiple icon sizes are written and the best
>> is chosen, but on freedesktops we only write 1 icon size at the
>> moment, and then it gets scaled to something like 64x64, so it really
>> does make a difference.
>
> OK.  I'll alter my patchset to be restricted to just Mac OS X.  Thanks for the heads-up.
>
> Personally, given what you say, I think the freedesktop-targeted code should obtain the actual height and width and then make its logic for picking the best size explicit about rejecting larger icons.  That is, it shouldn't just pick the apparently-largest icon and rely on 256x256 being "accidentally" zero-sized.
>
> Also, is it common for Windows icons to contain 64x64 variants?  My impression is that it's not, but I have no hard data about that.  In that case, it's typically better to scale down from a too-big icon than to scale a too-small (e.g. 48x48) icon up.  So, the freedesktop-targeted logic for picking a best size may want to pick 64x64 if present, the smallest size larger than that if available, then the largest size smaller than it as a last choice.

My argument wasn't just about quality, it was also about the picture
that's shown: the eMule 256x256 picture is different from the 64x64
picture, resulting in an icon that users wouldn't see on Windows
AFAIK.

On Gnome desktop icons look like they're 64x64, menus look 32x32 or less.

The real solution to all this on freedesktop is to write each icon
size into 16x16, 24x24, 32x32, 256x256 and such subdirectories under
~/.local/share/icons/hicolor/, then decipher the complicated
semi-broken logic of the icon theme spec and the xdg-icon-resource
tool's code (and probably Gnome's source code too) to figure out how
on earth they get Gnome to read those icons immediately. In my tests
with icons written this way, Gnome starts with a blank icon, then
refreshes to the actual icon only minutes later and only under
mysterious circumstances. Given this shakiness of icon handling, KDE,
XFCE, LXDE, and others will also require individual testing.

(You have to wonder why they had to pick single-image PNGs and then
require elaborate standards and filesystem layouts and multi-prefix
searches to support different icon sizes, followed by advanced caching
strategies to offset the abysmal performance, instead of just picking
a multi-image icon file format like Windows and MacOS did.)

Anyway I'll try to spare some time for it this weekend.

> Regards,
> Ken
>
>

Regards
Damjan