Rodent and png icons

[edscott wilson garcia]

El lun, 18-10-2004 a las 12:59, Jasper Huijsmans escribió:

> > 
> > I think the best way would be to put all required icons into the Rodent
> > theme (which is the default anyway), and just depend on that module.
> > Thus, duplication of pixmaps in other modules will be eliminated
> > (reducing unnecessary tarball swell). Fallback to the hicolor theme
> > would no longer be necessary, although there is no reason to remove it,
> > because it does work if the hicolor theme is correctly defined.
> > 
> 
> I want to get my icons if I chose another theme, as well. For that it 
> has to be in hicolor (fallback location).

Or fallback to Rodent which could inherit from hicolor... 

> 
> So, we either lookup icons in ${prefix}/share/icons/hicolor, regardless 
> of whether there is a proper index file (not pretty), or we use another 
> fallback location and look there, if all else fails. Those seem to me 
> the only options; any other ideas?
> 
> In this case it doesn't matter who installs the fallback icons, and 
> there is currently no way to depend on xfce4-icon-theme when building, 
> so I'd still prefer the panel to install its own fallback icons. But 
> anything that works is fine by me.
> 
> > The hacky way (IMO) would be during install have libxfcegui4, or
> > libxfce4util check the hicolor directory for the existance of the
> > icons.theme file and fix it if incorrect or missing. Then go ahead and
> > let each module put the necessary Rodent theme icons there. If the
> > Rodent theme is installed, this will be bloat, because the Rodent theme
> > is used first, being the default.
> > 
> 
> Too easy to break I think and indeed hacky. Also, Rodent may be the 
> default, it's not the fallback location.
> 
> > 
> >>Missing fallback icons are a release blocking issue for me, so let's try 
> >>to fix it as soon as possible.
> > 
> > 
> > Agreed. I see the issue as a block as well.
> > 
> > 
> >>Personally, I'd prefer it if the extra required logic for this would be 
> >>in the library, so that Xfce modules only have to use one API to get 
> >>this right.
> > 
> > 
> > Agreed totally. But I do not wish to be ill-treated either. I don't feel
> > to well about being ill-treated so in order to avoid any such
> > similarities in the future, 
> > 
> 
> I'm sure no-one meant to do that. If you feel that way, I'm very sorry.

Thank you. You have always been very polite, even when I have screwed
up, and you have never made me feel that way :-)

> 
> > I am thinking about:
>  > - Revert xfce-icontheme to it's previous "working" state (and wash my
> > hands).
> 
> Note that I haven't seen the problems, so I can't comment on this.


You can see bugs with inheritance and png icons. I've reverted all the
changes I have made to xfce-icontheme so that they may be verified: 
 
-if no svg icon is available, request an icon of size 48. The resulting
pixmap will scaled from any icon larger than 48 (preferably 192). You
can verify this by putting some debugging lines in xfce-icontheme. 

-on the same condition as above, if the 192 size icon is in an inherited
theme, this will be used even if there is an exact, better or worse
match for the requested theme. This is easy to verify: install the gnome
extra themes and select Crux theme. The folder icons in xffm are
displayed correctly since there is a 192 size icon in Crux. Now select
Sandy theme. Instead of getting the Sandy folder, you get the gnome
folder. This is because gnome has a 192 size icon and Sandy only gets up
to 96x96. Remove all gnome folder icons larger than 96, and the Sandy
folder will now be rendered.

-ask for an icon that exists in the theme in png format. If a
corresponding svg icon exists in an inherit theme, this will be chosen
instead of the requested theme icon.  

-ask for an icon which has an exact size. Instead of getting that, you
will get one scaled from the svg file (it is identical, save the cpu
overhead). Fixing this, problems appeared due to incorrect size fields
the Rodent theme: these have been corrected. The hicolor problem may be
related I don't know.

> 
> > - Remove the dependency of xfce4-modules/mime-icons on xfce-icontheme.
> > - Create static routines in xfce4-modules/mime-icons to cover the gap.
> > 
> > For the last point I will use the good stuff in Brian's code, but fix
> > the bugs and optimise the response. Currently to fetch an icon from the
> > Rodent theme, if gnome-icons are installed (evolution depends on it) 36
> > directories must be searched for possible files. And even more if the
> > Industrial theme is installed. That's brute force, which should not be
> > part of Xfce design if we are to remain lightweight.
> > 
> > IMO, inherited themes should only be searched if the requested icon is
> > not found. This would greatly enhance speed on applications where there
> > is a dependence on a large set of icons. I also plan to add an extra
> > parameter for icon lookup (which may be NULL in glib style) so that the
> > application can pinpoint the theme subdirectory. Otherwise there is no
> > reason for having a separate directory "mimetypes" in the icon themes.  
> > 
> 
> Very interesting. That sounds like it could speed up the lookup 
> considerably.

Speedup will not be noticeable unless you render many different icons.
The size fields can also be easily verified to work around broken
icon.theme files without problems. 

regards,

Edscott