Now that gtk+ 2.12.0 has been in the tree for a few weeks, a version of emul-linux-x86-gtklibs in sync with that version would be good. As usual with gtk+ upgrades, there are differences in things like gtk-engines that make 32-bit apps look terrible without commenting out new parameters in the associated gtkrc.
Gnome team is not maintaining these. Reassigning
In addition, would it be possible to get a wider selection of engines built? The default selection is kind of lacking.
Anyone working on this?
It will be part of my next round of emul building.. maybe this weekend.
It seems like that the theme engine ABI hasn't changed since the last version. Is there any specific theme that has stopped working correctly?
(In reply to comment #5) > It seems like that the theme engine ABI hasn't changed since the last version. > Is there any specific theme that has stopped working correctly? > The 32-bit Clearlooks engine crashes if /usr/share/themes/Clearlooks/gtk-2.0/gtkrc from the 64-bit theme is used unaltered. I believe the "colorize_scrollbar" and "toolbarstyle" statements need to be commented out, as well as references to GUMMY style, before the old engine will work with the new Clearlooks theme. At which point most of the new Clearlooks looks like the old version.
ok.. the problem is on the upgrade of gtk-engine to 2.20.. I'll upgrade the emul packages
emul-linux-x86-gtklibs-20071114 in the tree p.masked. use at your own risk.
Even with the fixed emul-linux-x86-gtklibs 20071118, there is still something missing in the 32-bit libraries. The issue that caused me to open this, inability of 32-bit gtk apps to handle the latest Clearlooks, is still there: $ realplay Gtk-Message: Failed to load module "gnomebreakpad": libgnomebreakpad.so: cannot open shared object file: No such file or directory /usr/share/themes/Clearlooks/gtk-2.0/gtkrc:68: error: unexpected identifier `colorize_scrollbar', expected character `}' This also happens with firefox-bin. In both cases, the gtk-engine crashes and the app has the ugly gtk1 look. 64-bit apps display with the new Clearlooks just fine (including the colorized scrollbar). Is there a 32-bit gtk-engines included? Would the lack of that be the problem here? I have gtk+ 2.12.1-r1 and gtk-engines 2.12.2 installed.
Thats from bug-buddy 2.20, the right solution here is potentially to unset GTK_MODULES from the env of binary apps, they dont need bug buddy anyway.
(In reply to comment #10) > Thats from bug-buddy 2.20, the right solution here is potentially to unset > GTK_MODULES from the env of binary apps, they dont need bug buddy anyway. > I understand the gnomebreakpad stuff is from bug-buddy. I was referring to the gtkrc error due to unexpected identifier. That is what crashes gtk-engines. See this upstream bug for more details: http://bugzilla.gnome.org/show_bug.cgi?id=386526 In the Clearlooks gtkrc, there are 4 lines that trigger this crash and have to be commented out for the 32-bit apps to have a normal appearance: 68, 70, 72 and 269. All these reference elements of the new Clearlooks theme. Perhaps I don't understand this clearly, but if /usr/lib32/gtk-2.0/2.10.0/engines/libclearlooks.so is the same engine version as /usr/lib64/gtk-2.0/2.10.0/engines/libclearlooks.so shouldn't it handle these new theme elements correctly?
Okay, it really looks like different versions between 32 and 64-bit. The identifiers that cause 32-bit Clearlooks to gack are: colorize_scrollbar toolbarstyle GUMMY So: $ strings /usr/lib64/gtk-2.0/2.10.0/engines/libclearlooks.so|grep -e colorize_scrollbar -e toolbarstyle -e GUMMY colorize_scrollbar toolbarstyle GUMMY $ strings /usr/lib32/gtk-2.0/2.10.0/engines/libclearlooks.so|grep -e colorize_scrollbar -e toolbarstyle -e GUMMY $ As a sanity check, menubarstyle doesn't cause problems with 32-bit, so: $ strings /usr/lib64/gtk-2.0/2.10.0/engines/libclearlooks.so|grep menubarstyle menubarstyle $ How can the new identifiers be missing if this is the correct engine?
We're still working on getting the listings updated on www.gentoo.org, so I won't tell you to look there. Here is what's in emul-linux-x86-gtklibs-20071118. If something needs to be matched, it's up to the 64bit side to do it. If you figure out what needs to be matched, please let me know and I'll add a blocker so it's not possible to mismatch. [ebuild R ] x11-libs/cairo-1.4.10 USE="X opengl -debug -directfb -doc -glitz -svg -xcb" [ebuild R ] dev-libs/atk-1.20.0 USE="-debug -doc" [ebuild R ] x11-libs/gtk+-1.2.10-r12 USE="nls -debug" LINGUAS="-az -ca -cs -da -de -el -es -et -eu -fi -fr -ga -gl -hr -hu -it -ja -ko -lt -nl -nn -no -pl -pt -pt_BR -ro -ru -s [ebuild R ] x11-libs/pango-1.18.3 USE="-debug -doc" [ebuild R ] media-libs/imlib-1.9.15-r1 USE="gtk -doc" [ebuild R ] x11-libs/gtk+-2.12.1-r1 USE="X cups jpeg tiff xinerama -debug -doc -vim-syntax" [ebuild R ] x11-themes/gtk-engines-2.10.2 USE="accessibility -debug -static" [ebuild R ] x11-themes/gtk-engines-xfce-2.4.1-r1
(In reply to comment #13) > > [ebuild R ] x11-libs/cairo-1.4.10 USE="X opengl -debug -directfb -doc > -glitz -svg -xcb" > [ebuild R ] dev-libs/atk-1.20.0 USE="-debug -doc" > [ebuild R ] x11-libs/gtk+-1.2.10-r12 USE="nls -debug" LINGUAS="-az -ca -cs > -da -de -el -es -et -eu -fi -fr -ga -gl -hr -hu -it -ja -ko -lt -nl -nn -no -pl > -pt -pt_BR -ro -ru -s > [ebuild R ] x11-libs/pango-1.18.3 USE="-debug -doc" > [ebuild R ] media-libs/imlib-1.9.15-r1 USE="gtk -doc" > [ebuild R ] x11-libs/gtk+-2.12.1-r1 USE="X cups jpeg tiff xinerama -debug > -doc -vim-syntax" > [ebuild R ] x11-themes/gtk-engines-2.10.2 USE="accessibility -debug > -static" > [ebuild R ] x11-themes/gtk-engines-xfce-2.4.1-r1 > gtk-engines is the only mismatch, which explains this issue. Current gtk-engines in Portage is 2.12.2. 2.10.x would not support the new Clearlooks theme. Thanks!
I discussed this with the gnome team. emul- ebuilds will only contain what's stable between amd64 or x86. You're running ~amd64, which is why you have the problem. gnome team is expecting this stuff to go stable in the next day or 2, at which time I'll roll another emul-linux-x86-gtklibs build and the problem will go away. if it takes longer than a day, I'll add a blocker/dep so you cannot get out of sync. Your choice currently is to downgrade to 2.10, change your theme, or wait a couple days for it to go stable and for me to roll a new set.
(In reply to comment #15) > Your choice currently is to downgrade to 2.10, change your theme, or wait a > couple days for it to go stable and for me to roll a new set. > I think I can wait a few days. ;-) Thanks for the explanation.
should be fixed in 20071121. reopen if not.
