Hi!
Hmm, do other GNOME applications work for you? I don't think that we do
anything special with the icon lookup, we just use what Gtk+ provides
(e.g. the path is determined by gtk+ not by anjuta).
If you want you can run anjuta in gdb with the "--g-fatal-warnings"
argument and post the backtrace here.
Regards,
Johannes
Am Montag, den 05.01.2009, 11:30 -0200 schrieb John Coppens:
> On Mon, 05 Jan 2009 11:20:24 +0100
> Johannes Schmid <jhs jsschmid de> wrote:
>
> Thanks for the reply.
>
> > Did you run "make clean" after changing the prefix?
>
> Yes - I'm quite sure I did that. Just to be sure, I just recompiled after
> a 'make clean', and still have the same problem. Strange is that most
> icons are visible, but I still get loads of:
>
> (anjuta:2127): Gtk-CRITICAL **: gtk_icon_info_load_icon: assertion
> `icon_info != NULL' failed
>
> (anjuta:2127): Gtk-CRITICAL **: gtk_icon_info_free: assertion `icon_info !
> = NULL' failed
>
> (anjuta:2127): GLib-GObject-CRITICAL **: g_object_unref: assertion
> `G_IS_OBJECT (object)' failed
>
> I straced anjuta startup, and these are the lines leading to the first of
> the above errors:
>
> stat64("/root/.icons/hicolor/index.theme", 0xbf87f27c) = -1 ENOENT (No such file or directory)
> stat64 ("/root/.local/share/icons/hicolor/index.theme", 0xbf87f27c) = -1 ENOENT (No such file or directory)
> stat64 ("/usr/local/share/icons/hicolor/index.theme", 0xbf87f27c) = -1 ENOENT (No such file or directory)
> stat64 ("/usr/share/icons/hicolor/index.theme", {st_mode=S_IFREG|0644, st_size=16882, ...}) = 0
> write(2, "\n(anjuta:2158): Gtk-CRITICAL **:"..., 95 (anjuta:2158): Gtk-CRITICAL **: gtk_icon_info_load_icon: assertion `icon_info != NULL' failed
>
> It doesn't look for /opt/gnome/share/icons/gnome/index.theme
>
> John
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil