GNOME Bugzilla – Bug 321819
broken emblem size logic
Last modified: 2008-07-08 10:13:51 UTC
Please describe the problem: We've been shipping embelms with gnome icon theme that are the wrong size. The directory structure of an icon theme consists of $size/$category/$icon. The emblems category however doesn't currently correspond to the $size. Emblems in $48x48 are in fact 32x32 pixels. Nautilus shouldn't be using 48x48 emblems for 48x48 icons. This is even more striking for scalable icon themes where canvas is the same for all icons but emblems. Steps to reproduce: 1. Download the tango icon theme which ships with emblems sized exactly the same as all other icons. 2. Notice the emblems are fricken huge in nautilus. Actual results: http://jimmac.musichall.cz/screenshots/huge-emblems.png Expected results: I suggest nautilus takes 1/4 size of the actual icon for the emblem target canvas, that is 24x24px. Does this happen every time? Other information:
Ummm, isn't this a bug in the icon theme, then? You are considering $size to mean "emblems should be size x size pixels", rather than "emblems should make sense for an icon that is of this size". (Why do the emblems in the default theme work fine? Are they really smaller than the corresponding icons in the icon theme?)
It is a bug in the gnome icon theme. I was thinking opening this bug first before "breaking" the theme into what I believe is the correct structure. Gnome icon theme currently ships 32x32pixel emblems claiming they are 48x48.
When an icon theme has NxN/emblems/foo.png does it mean foo.png is an emblem suitable for icons which are NxN pixels in size? Or does it mean that foo.png is at most NxN pixels big, and it should only be used for icons which are (say) 3*N x 3*N pixels big?
NxN denotes the size of icons which are in that folder. The Size= attribute in the index.theme file for theme, specifies this size in one direction. It is expected that icons are always on a square canvas, and designed to the size specified by the directory containing the icon, and the Size= attribute of the directory as specified in the index.theme. For scalable icons, in the Tango theme, this would be 48x48. The scalable icons may be scaled to a large number of sizes, but really should not be scaled down or up too much. Nautilus should really be determining what size emblems to use, based on the size of the icon being shown for the file. Regardless of the fact that the Tango emblems are all 48x48 now, even previously, if you had thumbnails turned on, and made a symlink to a very small image, like a 16x16 icon, the emblem would basically entirely cover the icon. Same problem really, it just now happens on icons that are 48x48 as well, with the Tango theme. I think the 1/4 size icon selection would probably be best, although we probably want to either disable emblems on top of icons that are very small, or disable thumbnails for them, so that emblems can be properly used. Emblems are still quite annoying in list view as well.
I suggest we either get rid of the emblem context from the icon theme and ship emblems along with nautilus with the current logic, or consider emblems as icons, keep them in the icon theme but let them follow the same size principles as any other icons. Having emblem icons be placed in 48x48 directory, being 32x32 and claiming they are 48x48 in the index.theme is flawed.
I tend to agree with comment 5, NxN theme directories should only contain NxN icons, that is. I'm reassigning this one to gnome-icon-theme since the current lookup algorithm doesn't force any precise size matches as demanded in comment 4, and special-casing emblem icon size lookups sounds awful.
So, Christian, why did you re-assign this to gnome-icon-theme? Nautilus is still broken with the way it handles emblems. Even if I disable read access to the emblems directories in my installation of Tango, for sizes above 16, to force Nautilus to use the 16x16 emblems, it scales them UP, despite the fact that they are clearly marked Fixed in the index.theme. The only thing worse than a nice crisp 48x48 svg covering up your folder icon, is a 16x16 bitmap scaled up to 48x48, covering up your folder icon. Why is it scaling these non-scalable icons? Even if I generate some 32x32 bitmaps, they still get scaled up to match the folders. I don't know why special casing of emblems sounds awful. Nautilus does it already. And emblems need to be special cased at some point anyway. They are icons meant to be composited on top of a partial region of other icons. Back to Nautilus. I'm not sure how you expect this to get fixed solely through git.
*** Bug 340144 has been marked as a duplicate of this bug. ***
Confirming.
Created attachment 69540 [details] [review] Patch to use minimum emblem size of (icon_size / 2) This patch should fix this problem by using emblems that are half the width of the icon they are going on top of, in most cases. This means 8x8 gets used in the list view (or whatever size most closely satisfies that), 16x16 for 32x32 icons, 24x24 for 48x48, and so on, with the MAXIMUM_EMBLEM_SIZE remaining at 48, as defined in the code already. Can someone please review this patch and get it in for 2.16? It would help the icon theming situation a lot.
Thank you! This patch works fine here: Gnome 2.15.4/Nautilus 2.15.4 Gentoo/AMD64.
Actually, let me amend that -- the link emblem looks fine, but the other emblems look more like 1/4 size instead of 1/2, which makes them a bit too small.
Sorry to spam this bug, I should have spent more time testing before posting. It seems like several emblems are the correct size (link unreadable, favorite, shared, important) and others are the smaller size. The distance between multiple emblems seems based on the smaller size, so some emblems are superimposed on others if several are selected. This occurs with both the default gnome icon theme and tango (which is my usual theme).
I think that is due to the fact that tango doesn't provide all the emblems yet, and gnome-icon-theme doesn't provide them all at all sizes, and in the correct size yet, either. But I would consider that an issue with the icon theme itself, rather than the emblem implementation. Glad to hear it works. Thanks. :)
I see this patch didn't make it into 2.15.90, nor is it in the CVS changelog. Is it going into 2.15.91, or do the themes that have emblems that don't work well with this patch have to be updated before it does?
We can fix the themes later. And we still have a few weeks to get this patch in, I think. Up until the hard code freeze anyway, afaik. But it should definitely go in.
*** Bug 318726 has been marked as a duplicate of this bug. ***
So, anyone? Can I commit this to HEAD?
Please send it to nautilus-list for review. Thanks in advance.
Looks like the fix is in nautilus 2.15.92. Thanks!
Jose, that release doesn't exist, and it's not fixed in CVS HEAD. You must still have the patch applied and not noticed. :)
Yes, I meant .91, and yes the 2.15.91 ebuild still applies the patch. Which should teach me never to comment on a bug after coming back from having a couple of beers with a friend...
Seems like this has not made it into the final nautilus-2.16.0/gnome-icon-theme-2.16.0 releases, right? At least my 2.16 desktop doesn't look like it. If this is true, then please consider this comment as a friendly *bump*. :-)
Yes, this patch is not in nautilus yet. Updating the version to reflect that.
Just for the record: after both applying the half-size patch and running 'mogrify -resize 48x48 /usr/local/share/icons/gnome/48x48/emblems/*.png; gtk-update-icon-cache -f /usr/local/share/icons/gnome', the emblems in nautilus *finally* look sane again. Thanks!
Is it possible to see this patch in main tree?
Is it too late for this patch to make it into 2.18? In what is an otherwise attractive desktop, this is an embarrassing-looking blemish that really stands out. So much so that when I show off my Gnome/Beryl desktop to impress on my friends how much more advanced Linux is than Windows, I make sure to stay away from opening any folders with symlink emblems!
Ouch. This ugly bug is still present on my freshly compiled and otherwise beautifully looking GNOME-2.18 desktop. I just filed an additional bug report against gnome-icon-theme for the 32x32 PNGs in $(prefix)/share/icons/gnome/48x48/emblems, see bug #419203 - here's hoping that we'll finally see this fixed in 2.20, 3.0, or at least GNOME XP or Vista. 8-) Meanwhile, back to comment #25.
*** Bug 419203 has been marked as a duplicate of this bug. ***
Come on, this bug should've been fixed long time ago. Nautilus people, don't slack and make your users happy ;-) Bumping severity.
We're at 2.19.4 and this bug is still present. There's still plenty of time to get it in before code freeze and eliminate this bit of ugliness! Nautilus devs, can we get a bit of action here? ;-)
Indeed would be nice to have this before 2.20, our users will be dancing if you fix this :-P
Please also so http://mail.gnome.org/archives/nautilus-list/2007-July/msg00002.html for Alex take on this.
Created attachment 97431 [details] Nautilus with emblems at 75% Well, 2.20 was released a few weeks ago, and this wasn't fixed. There are some emblems which are not scalable (like Music) which should be redone (hope #469407 wil fix this). And the emblem logic for small views is quite broken: * 75% (displays as 67% in Nautilus windows): the emblem is placed on the middle of the icon, and if you have more than one emblem, they get placed weirdly. * 50%: no emblems? Attached is screenshot for 75% view.
Created attachment 97432 [details] Nautilus with emblems at 100% Look at the music emblem is very small...
Would be nice fix this before nautilus 2.22 relase :-) Thanks a lot
This still isn't fixed properly as of GNOME 2.22. Granted, it's not as bad and obvious anymore as it used to be, but something still isn't quite right. First, the PNG icons in /usr/local/share/icons/gnome/48x48/emblems/ are still actually 32x32, while all other icons in /usr/local/share/icons/gnome/*/emblems/ have sizes corresponding to the directory name they're located in. This just *cannot* be right, or can it (although it's probably a bug in gnome-icon-theme rather than nautilus)? [zlatko@disclosure]:/usr/local/share/icons/gnome$ file */emblems/emblem-default.png 16x16/emblems/emblem-default.png: PNG image data, 16 x 16, 8-bit/color RGBA, non-interlaced 22x22/emblems/emblem-default.png: PNG image data, 22 x 22, 8-bit/color RGBA, non-interlaced 24x24/emblems/emblem-default.png: PNG image data, 24 x 24, 8-bit/color RGBA, non-interlaced 32x32/emblems/emblem-default.png: PNG image data, 32 x 32, 8-bit/color RGBA, non-interlaced 8x8/emblems/emblem-default.png: PNG image data, 8 x 8, 8-bit/color RGBA, non-interlaced [zlatko@disclosure]:/usr/local/share/icons/gnome$ Second, I'll attach a screenshot showing a directory with the "read-only" and "symbolic-link" emblems (these are from tango-icon-theme-0.8.1, and apparently properly sized) and a directory with the "desktop" emblem (this is a fallback from gnome-icon-theme-2.22.0, as tango doesn't provide this emblem). The screenshot was taken without the "half-size patch" for nautilus, and without upscaling the PNGs in the 48x48 directory to 48x48. It's quite obvious that although the "desktop" emblem isn't quite as huge as anymore it used to be in earlier versions, it's still noticeably larger than the two emblems of the other directory. For a direct comparison, to "chmod u-w ~/Desktop", resulting in an additional "read-only" emblem directly below the "desktop" emblem.
Created attachment 111340 [details] screenshot showing the current state as of GNOME-2.22
The nautilus side has been fix, whatever remains is a problem with gnome-icon-theme. Closing.