After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 321819 - broken emblem size logic
broken emblem size logic
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: [obsolete] Backgrounds Emblems and Themes
0.x.x [obsolete]
Other All
: High major
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 318726 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-11-18 19:03 UTC by Jakub Steiner
Modified: 2008-07-08 10:13 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16


Attachments
Patch to use minimum emblem size of (icon_size / 2) (719 bytes, patch)
2006-07-25 00:21 UTC, Rodney Dawes
none Details | Review
Nautilus with emblems at 75% (35.56 KB, image/png)
2007-10-18 16:47 UTC, Adolfo González Blázquez
  Details
Nautilus with emblems at 100% (38.66 KB, image/png)
2007-10-18 16:48 UTC, Adolfo González Blázquez
  Details
screenshot showing the current state as of GNOME-2.22 (6.39 KB, image/png)
2008-05-22 14:21 UTC, Thomas Zajic
  Details

Description Jakub Steiner 2005-11-18 19:03:50 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:
Comment 1 Federico Mena Quintero 2005-11-22 21:41:16 UTC
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?)
Comment 2 Jakub Steiner 2005-11-22 22:37:53 UTC
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.
Comment 3 Federico Mena Quintero 2005-11-23 00:38:52 UTC
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?
Comment 4 Rodney Dawes 2005-11-23 02:13:45 UTC
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.
Comment 5 Jakub Steiner 2005-12-06 17:04:00 UTC
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.
Comment 6 Christian Neumair 2006-03-17 11:09:11 UTC
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.
Comment 7 Rodney Dawes 2006-03-17 12:42:17 UTC
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.
Comment 8 Rodney Dawes 2006-05-16 20:14:18 UTC
*** Bug 340144 has been marked as a duplicate of this bug. ***
Comment 9 Rodney Dawes 2006-05-16 20:14:47 UTC
Confirming.
Comment 10 Rodney Dawes 2006-07-25 00:21:11 UTC
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.
Comment 11 Jose M. daLuz 2006-07-25 01:00:37 UTC
Thank you! This patch works fine here: Gnome 2.15.4/Nautilus 2.15.4 Gentoo/AMD64.
Comment 12 Jose M. daLuz 2006-07-25 01:05:57 UTC
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.
Comment 13 Jose M. daLuz 2006-07-25 01:15:00 UTC
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).
Comment 14 Rodney Dawes 2006-07-25 01:37:53 UTC
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. :)
Comment 15 Jose M. daLuz 2006-07-28 23:40:50 UTC
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?
Comment 16 Rodney Dawes 2006-07-29 00:46:26 UTC
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.
Comment 17 Rodney Dawes 2006-07-29 04:27:39 UTC
*** Bug 318726 has been marked as a duplicate of this bug. ***
Comment 18 Rodney Dawes 2006-07-29 20:07:03 UTC
So, anyone? Can I commit this to HEAD?
Comment 19 Christian Neumair 2006-07-29 21:19:51 UTC
Please send it to nautilus-list for review. Thanks in advance.
Comment 20 Jose M. daLuz 2006-08-10 03:55:15 UTC
Looks like the fix is in nautilus 2.15.92. Thanks!
Comment 21 Rodney Dawes 2006-08-10 11:52:35 UTC
Jose, that release doesn't exist, and it's not fixed in CVS HEAD. You must still have the patch applied and not noticed. :)
Comment 22 Jose M. daLuz 2006-08-10 12:00:07 UTC
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...
Comment 23 Thomas Zajic 2006-09-07 15:10:16 UTC
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*. :-)
Comment 24 Rodney Dawes 2006-09-07 17:11:32 UTC
Yes, this patch is not in nautilus yet. Updating the version to reflect that.
Comment 25 Thomas Zajic 2006-11-29 22:43:09 UTC
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!
Comment 26 Oleksij Rempel 2007-01-16 11:24:15 UTC
Is it possible to see this patch in main tree?
Comment 27 Jose M. daLuz 2007-02-14 03:05:17 UTC
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!
Comment 28 Thomas Zajic 2007-03-17 02:43:10 UTC
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.
Comment 29 Rodney Dawes 2007-03-17 06:41:45 UTC
*** Bug 419203 has been marked as a duplicate of this bug. ***
Comment 30 Wouter Bolsterlee (uws) 2007-05-06 21:06:14 UTC
Come on, this bug should've been fixed long time ago. Nautilus people, don't slack and make your users happy ;-)

Bumping severity.
Comment 31 Jose M. daLuz 2007-07-01 15:25:27 UTC
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? ;-)
Comment 32 Pedro Villavicencio 2007-07-31 01:40:46 UTC
Indeed would be nice to have this before 2.20, our users will be dancing if you fix this :-P
Comment 33 Martin Wehner 2007-07-31 02:00:59 UTC
Please also so http://mail.gnome.org/archives/nautilus-list/2007-July/msg00002.html for Alex take on this.
Comment 34 Adolfo González Blázquez 2007-10-18 16:47:39 UTC
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.
Comment 35 Adolfo González Blázquez 2007-10-18 16:48:52 UTC
Created attachment 97432 [details]
Nautilus with emblems at 100%

Look at the music emblem is very small...
Comment 36 Pacho Ramos 2007-10-28 11:18:19 UTC
Would be nice fix this before nautilus 2.22 relase :-)

Thanks a lot
Comment 37 Thomas Zajic 2008-05-22 14:19:14 UTC
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.
Comment 38 Thomas Zajic 2008-05-22 14:21:07 UTC
Created attachment 111340 [details]
screenshot showing the current state as of GNOME-2.22
Comment 39 Jakub Steiner 2008-07-08 10:13:51 UTC
The nautilus side has been fix, whatever remains is a problem with gnome-icon-theme. Closing.