Rodent and png icons

[Jasper Huijsmans]

edscott wilson garcia wrote:
...
>>
>>Right, I think I asked about this behaviour when brian implemented the 
>>icon theme stuff. I don't remember what was decided, but the panel 
>>relies on the fact that we can put our fallback icons in 
>>${datadir}/icons/hicolor/. If this isn't guaranteed to work, how would 
>>you suggest implementing this?
> 
> 
> 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).

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.

> 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.

> - 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.

> Although my priorities are well defined and Xfce is high on the list, I
> have to work overtime to finish a lot of backlogged work, so I probably
> won't get into the above until Wednesday or Thursday. 
> 

I'll won't have any time this week, at all :/

	Jasper