qtgui places /etc/profile.d/qtgui.sh which exports GTK2_RC_FILES=${HOME}/.gtkrc-2.0 which in turn causes Gtk 2 applications to fail theming. I don't think qtgui has any business messing with the environment in that manner and should not create any such file.
I can't find any package that installs </etc/profile.d/qtgui.sh>. Can you provide some evidence that dev-qt/qtgui does this? Also, post your `emerge -vpq dev-qt/qtgui' output if that is the case.
I misspelled. The name of the file is "/etc/profile.d/qtgui4.sh". `equery belongs` reports "dev-qt/qtgui-4.8.5-r1 (/etc/profile.d/qtgui4.sh)" [ebuild R ] dev-qt/qtgui-4.8.5-r1 USE="exceptions glib gtkstyle xv -accessibility (-aqua) -cups -debug -egl -mng -nas -nis -pch -qt3support -tiff -trace -xinerama"
I assume the gtkstyle flag is responsible.
What problems does it cause exactly?
In my particular case GTK2 applications would no longer find their style (because my gtkrc resides in /etc). I'm saying that it should generally not be any package's (least of all: QT's) business to modify the GTK2_RC_FILES environment variable, even *if* it managed to do it correctly. This bug is just evidence for it being principially wrong. Therefore, I consider bug 388551 invalid. As long as QT uses GTK's environment variable, it should not do any modifications to it on installation.
CCing gnome for ideas because we added this file at their suggestion, and gtk+ is their domain.
Just as an idea: What if QT introduces its own environment variable, sth. like QT_GTK_RC_FILES, if that makes any sense. What appears inconsistent and thus the origin of this issue is the fact that for QT (GTKish) theming, GTK2_RC_FILES is mandatory whereas for GTK itself, it is not (in other words: GTK and QT use different mechanisms to determine the GTK style but overlap on the GTK2_RC_FILES environment variable). So it appears the easiest way to untangle the situation (without replicating GTKs exact mechanism to determine the style) is to give QT its own variable.
I don't see any theming issue here, what exact app are you using? Does it show any error when launched from a terminal? What does $ echo $GTK2_RC_FILES output for you? What are the contents of your $GTK2_RC_FILES file?
Any GTK2 application fails theming (of those I have). Among which Inkscape, Firefox, gvim. No errors on CLI. echo $GTK2_RC_FILES would have printed "/home/manday/.gtkrc-2.0" if I had executed it before I deleted qtgui4.sh. The contents of my /home/manday/.gtkrc-2.0 are ill-defined, because I do not have any such file. As I said, my gtkrc is system wide and resides in /etc/gtk-2.0
Then, I cannot reproduce that problem and I have exactly the same setup: $ echo $GTK2_RC_FILES /home/pacho/.gtkrc-2.0 $ LC_ALL=C ls -l /home/pacho/.gtkrc-2.0 ls: cannot access /home/pacho/.gtkrc-2.0: No such file or directory
Or maybe it's "hidden" because libgnomeui isn't installed in your setup but it's present on mine :|
So... should we just remove the file again?
Can you provide some steps to reproduce the problem? (from what desktop file are you trying to run gtk apps?)
(In reply to Pacho Ramos from comment #13) > Can you provide some steps to reproduce the problem? (from what desktop file > are you trying to run gtk apps?) The problem is that QT should not modify the environment. It should generally never do this. To reproduce the problem of GTK2 apps failing to theme if the environment is wrong just run (with 2.24.22) GTK2_RC_FILES=~/doesntexist inkscape
It still works but I guess because gnome-settings-daemon takes care of rendering it correctly, that makes me also wonder is we really need to set that to any value :/ I guess all this problem we are trying to handle is this one: https://wiki.archlinux.org/index.php/Uniform_Look_for_Qt_and_GTK_Applications#Qt_applications_do_not_use_QGtkStyle
Can we add the /etc file to GTK2_RC_FILES as well? Otherwise, as I said, we could just remove the qtgui4.sh file, close 388551 as WONTFIX and let users deal with theme configuration. Depending on libgnomeui/gconf is not an option IMO.
Do you know how other distributions handle this? Regarding /etc, we only provide /usr/share/gtk-2.0/gtkrc that simply sets a fallback icon theme :|
(In reply to Pacho Ramos from comment #17) > Do you know how other distributions handle this? No. Honestly, the qt gtkstyle has always been a huge PITA for us, and I'm not going to waste time any more on this. So I think I'll just go ahead and revert the change that introduced the profile.d file.
Please give me some hours to check in other distros (can't do it just now, but with less than a day will be enough), only give me some hours and will report back :)
This is how Fedora handles it (it's also the solution from upstream): http://pkgs.fedoraproject.org/cgit/qt.git/tree/qt-everywhere-opensource-src-4.8.5-qgtkstyle_disable_gtk_theme_check.patch -> they apply this patch removing the check for old gconf setting as explained in: https://bugreports.qt-project.org/browse/QTBUG-5545 https://bugzilla.redhat.com/show_bug.cgi?id=702493 Once it's applied, nothing more is needed (neither gtkrc hack neither libgnomeui dependency)
As of recently, GTK2_RC_FILES=/home/manday/.gtkrc-2.0 has re-appeared, though this time, I can't find the origin of it. It used to be recreated in env, however, I deleted it from there, ran env-update and rebooted. The environment variable is still there, though. Do you have anything to do with this?
(In reply to Cedric from comment #21) > As of recently, GTK2_RC_FILES=/home/manday/.gtkrc-2.0 has re-appeared, > though this time, I can't find the origin of it. It used to be recreated in > env, however, I deleted it from there, ran env-update and rebooted. The > environment variable is still there, though. Do you have anything to do with > this? Nope.
(In reply to Pacho Ramos from comment #20) > This is how Fedora handles it (it's also the solution from upstream): > http://pkgs.fedoraproject.org/cgit/qt.git/tree/qt-everywhere-opensource-src- > 4.8.5-qgtkstyle_disable_gtk_theme_check.patch > > -> they apply this patch removing the check for old gconf setting as > explained in: > https://bugreports.qt-project.org/browse/QTBUG-5545 > https://bugzilla.redhat.com/show_bug.cgi?id=702493 > > Once it's applied, nothing more is needed (neither gtkrc hack neither > libgnomeui dependency) Patch applied in overlay for the live ebuild, will be applied to 4.8.6 too once it's bumped.
Fixed in 4.8.5-r3
