Re: Patch to fix #321819

[Rodney Dawes <dobey novell com>]

On Wed, 2006-08-23 at 14:20 +0200, Alexander Larsson wrote:
> On Tue, 2006-08-22 at 15:59 -0400, Rodney Dawes wrote:
> > On Tue, 2006-08-22 at 12:17 +0200, Alexander Larsson wrote:
> > > On Mon, 2006-08-21 at 16:58 -0400, Rodney Dawes wrote:
> > > > Hey guys,
> > > > 
> > > > The emblem size choosing logic in Nautilus is rather problematic at the
> > > > moment, allowing the smallest size of the emblem to be the same size as
> > > > the icon itself, that the emblem is being attached to. The attached
> > > > patch fixes this by using a minimum size of half the icon size, for the
> > > > emblem size, allowing more appropriately sized icons to be used, and
> > > > allowing theme authors to put correctly sized icons in their themes'
> > > > emblems directories, rather than having to kluge around having icons
> > > > that are actually smaller than the theme says they are.
> > > > 
> > > > Can I please get this committed for 2.16? Thanks.
> > > 
> > > I'm not sure the icon theme spec ever said that the icons have to be
> > > exactly the size the directory specified. They just were designed for
> > > that size. Thats how the emblems in nautilus always worked, instead of
> > > deciding a specific size for the emblems they were designed for a
> > > particular target size.
> > 
> > The specification implies it, whethere it specifically states it or not.
> > If this is a matter of confusion, we should fix the spec to clearly
> > state that the size of the icons in a directory, must match the size
> > which is specified for that directory. That is in fact what the point of
> > the Size= in index.theme is for, I presume. And yes, nautilus has always
> > been broken in wanting emblem icons to be drawn the way they have been
> > in the past. The current situation is much worse than it seems at first.
> > A number of themes have icons at fairly arbitrary sizes inside the
> > emblems directory for a particular size of icons. Nowhere currently is
> > there a specification of how to manage the emblems directory. It seems
> > like an appropriate time to improve this situation, by fixing the emblem
> > lookup code in nautilus, and standardizing how things work for emblems,
> > more appropriately to match the rest of the theme. Especially if we ever
> > want other desktops to adopt the emblem methodology.
> 
> I don't see why we have to change the nautilus lookup code just because
> some icon themese are broken.

And I don't see why we have to make the icon themes be broken, just
because the nautilus implementation is. Making this argument is
pointless. All it does is point out that we disagree on what's broken.
We can sit here and say this over and over and nothing will change.

>  They will continue to be broken after we
> change it. Isn't it better to fix these themese instead (and perhaps
> write some docs for how it works). For all the time that nautilus has
> supported themed emblems they have worked the same way, emblems for
> icons of a particular size go into a directory with the same base size
> as the icon. We also handle resizing fine all over the nautilus code by
> resizing an icon based on the base size of the icon directory, not the
> actual size of the icon.

I would be happy to fix the themes. But fixing the themes to be the way
you are implying they should be, is not fixing them. It's a workaround
to deal with the broken logic in nautilus. Because nautilus has always
worked this way, doesn't mean it wasn't always broken. And nautilus in
fact doesn't handle resizing fine, because it means I can't draw emblems
to the size specified for the directory, and have them work properly.

> Not only is this how things currently work. I also think its a much
> better way whan just picking an abitrary size for the emblems (like 50%
> of the icon size in your patch). It means the various emblems can differ
> in sizes as needed for a specific icon size.

The size isn't arbitrary. If you have four emblems on an icon, the most
appropriate size for those emblems is obviously 1/4 the area of the
icon, which is icon_size / 2. The various emblems can differ in size
already. Changing the size to size / 2 isn't going to change that fact.

> Also, this isn't the only icon that isn't the same size as the directory
> base size. The same happens with process-working/gnome-spinner. Neither
> of these are gonna cause problems, because only emblem using apps (at
> this time, only nautilus) will ever read the emblems, and only spinner
> apps the spinner icon. 

The spinner icon has frames which are the size specified for the
directory. And yes, the spinner implementations in nautilus and epiphany
are very much broken as well, as they always ask for a size of -1, and
then try to scale it to whatever sizes they need. But that's a different
set of bugs, which are filed, and are not the subject of this thread. As
it stands, I would also be quite happy to change the spinner icon to use
APNG as a format instead, or something else seemingly appropriate, given
that the toolkits would support it.

> > > Even if we want to change this I'm not sure the best time to do so is
> > > when we're hard code frozen. Won't this break every currently working
> > > themed emblem?
> > 
> > According to http://live.gnome.org/TwoPointFifteen the hard code freeze
> > is not until next Monday, August 28. I wouldn't say that the change will
> > break every currently working theme. It will cause emblem icons to be
> > rendered smaller, though.
> 
> Still, its kind of late to do a change that requires all icon themes to
> change unless they want to look quite broken.

All of the icon themes providing emblems at consistent sizes won't look
broken. The icons might look slightly smaller. But looking broken is a
very subjective measuremnt to try and state. The emblems implementation
itself is very arbitrary in nature to begin with. The code simply lists
every icon in the emblems context, and there is no guarantee that
another theme will have the same icon, and gnome-icon-theme certainly
doesn't, and isn't going to, provide all possible icons that all other
themes might stick in emblems. This patch, along with specifying a set
of emblems via the icon naming spec, and documentation of how an emblem
implementation should work, will greatly improve the situation here.
Fixing the few icon themes that do exist, to fall in line with these
changes, is hardly an issue.

-- dobey