bug with gtk2

[bmarkus]

Either way, that index file should be created and place in the extension that contains the hicolor icons, using the gtk-update-icon-cache command.

No, index file is not created by gtk-update-icon-cache, only the cache which is optional and not a must heve.:

It expects to be given the path to a icon theme directory containing an index.theme, e.g. /usr/share/icons/hicolor, and writes a icon-theme.cache containing cached information about the icons in the directory tree below the given directory.

GTK+ can use the cache files created by gtk-update-icon-cache to avoid a lot of system call and disk seek overhead when the application starts. Since the format of the cache files allows them to be mmap()ed shared between multiple applications, the overall memory consumption is reduced as well.

Adding index.theme without cache works fine.

See http://library.gnome.org/devel/gtk/unstable/gtk-update-icon-cache.html

EDIT:

Tested rhytmbox, adding the index.theme few more icons are visible in its menu.

[bmarkus]

The hicolor theme seems to be part of the gnome-media extension.  Not sure if it should be there or it's own extension as it is a source unto itself.  Either way, that index file should be created and place in the extension that contains the hicolor icons, using the gtk-update-icon-cache command.

EDIT:  It seems only the relevant icons from gnome-media are in the hicolor directory.  Perhaps a hicolor icon extension will fix the issue.

The hicolor icon theme itself is a placeholder for the default fallback theme, filled by applications like gnome-media and others. I will submit it shortly as an independent extension, which also contains the index file. It will solve the problem.

Regarding missing .gtkrc-2.0 default can go to the gnome-icon-theme extension as it refers to it. Normally it is not edited manually but by gtk theme changer programs. As it is in the home directory, changes saved automatically with backup. Backup is restored after extensions loaded and startup scripts executed, default value will be overwritten from backup so no any harm to have it.

As an icon theme changer, lxappearance works fine. It is desktop independent, no need LXDE to use.

[jls]

Using this check, gtk shows svg support:

gdk-pixbuf-query-loaders | grep svg

output:

"/usr/local/lib/gtk-2.0/2.10.0/loaders/svg_loader.so"
"svg" 2 "gtk20" "Scalable Vector Graphics" "LGPL"
"image/svg+xml" "image/svg" "image/svg-xml" "image/vnd.adobe.svg+xml" "text/xml-svg" "image/svg+xml-compressed" ""
"svg" "svgz" "svg.gz" ""
" <svg" "*    " 100
" <!DOCTYPE svg" "*             " 100

I don't think a gtk rebuild will help, seems like some apps are a casualty of the changes in the latest gtk like the gdk window thing.

tucan doesn't start anymore:

Code: [Select]

Couldn't recognize the image file format for file '/mnt/hda3/jls/estensioni/tucan/tmp/usr/local/share/tucan/media/tucan.svg'

Code: [Select]

tc@box1:~$ gdk-pixbuf-query-loaders | grep svg
tc@box1:~$

[Jason W]

Thanks, I will look into it tonight.

[Jason W]

The dep files and startup scripts of the related extensions - gtk2, gdk-pixbuf2, and librsvg - seem to be right.  But I read a similar issue with Arch Linux and the latest gtk2, and there the fix was to update librsvg to the latest version 2.32.0.   I have a hunch that may be the issue here.  I am not on a Linux box to test it now, but librsvg could use an update anyway.  I will see tonight if that fixes it.

[Jason W]

Confirmed, an update of librsvg to it's latest stable release fixes the issue.

[Juanito]

I should be able to update librsvg in the next couple of days

[Juanito]

updated librsvg posted