Version: unspecified (using KDE 4.5.3) OS: Linux We had a (confirmed) report that some qt apps, specifically VLC, did not work correctly when run in a non-qt/kde environment. I don't recall details off the top of my head, but the conclusion reached was that the app in question did not know how to find the gtk theme when being run outside of KDE, and the solution was to populate GTK2_RC_FILES in the environment before starting the X session if we're not running KDE. [1] We added a profile script that does this: GTK2_RC_FILES="/etc/gtk-2.0/x86_64-slackware-linux/gtkrc:/etc/gtk-2.0/gtkrc:$HOME/.gtkrc-2.0" As expected, this solves the VLC issue, but it introduces a new problem. Before we added that profile script, GTK apps that were launched from within KDE would have a theme matching the current QT theme; however, after adding the profile script, they always match the theme defined *last* in GTK2_RC_FILES. That seems easy enough to work around, right? We can just add the path that KDE uses to write its gtkrc file, which is $HOME/.kde/share/config/gtkrc-2.0, as defined in krdb.cpp. Of course, now we have created *another* problem. If a user logs into KDE, she will have $HOME/.kde/share/config/gtkrc-2.0 created to match her QT theme selected, and then when she logs out of KDE and returns to her old favorite DE, which happens to be XFCE, she gets a surprise -- all of her apps will be using the QT-looking theme since GTK2_RC_FILES contains the $HOME/.kde/share/config/gtkrc-2.0 patch in it. Soo... how to solve this? It seems to me that krdb should read in the value of GTK2_RC_FILES and then append $HOME/.kde/share/config/gtkrc-2.0 to it (and then use that as expected). This would IMHO be the best way to handle it, but there is at least one other option: we (Slackware) can patch /usr/bin/startkde to append $HOME/.kde/share/config/gtkrc-2.0 to GTK2_RC_FILES. Thoughts? [1] What part of KDE *populates* GTK2_RC_FILES if it's currently empty when KDE starts? Unless I missed something obvious, it doesn't seem to be happening in krdb.cpp, yet *something* is populating it: if we don't set it in the environment already before launching KDE, then we can see in the output of "env" that it is set and contains $HOME/.kde/share/config/gtkrc-2.0 in it... :/ Reproducible: Always
Well, apparently editing /usr/bin/startkde is *not* an option... Immediately after this section of the script: kdehome=$HOME/.kde test -n "$KDEHOME" && kdehome=`echo "$KDEHOME"|sed "s,^~/,$HOME/,"` I added this: # Inherit existing GTK_RC_FILES and GTK2_RC_FILES and append kde-specific path GTK_RC_FILES="$GTK_RC_FILES:$kdehome/share/config/gtkrc" GTK2_RC_FILES="$GTK2_RC_FILES:$kdehome/share/config/gtkrc-2.0" export GTK_RC_FILES GTK2_RC_FILES With some debugging 'echo' statements around that block, here's what I see: GTK_RC_FILES before is unset. GTK2_RC_FILES before is /etc/gtk-2.0/x86_64-slackware-linux/gtkrc:/etc/gtk-2.0/gtkrc:/home/rworkman/.gtkrc-2.0 GTK_RC_FILES after is :/home/rworkman/.kde/share/config/gtkrc GTK2_RC_FILES after is /etc/gtk-2.0/x86_64-slackware-linux/gtkrc:/etc/gtk-2.0/gtkrc:/home/rworkman/.gtkrc-2.0:/home/rworkman/.kde/share/config/gtkrc-2.0 However, once kde is running, I get this from "env | grep GTK": GTK2_RC_FILES=/etc/gtk-2.0/x86_64-slackware-linux/gtkrc:/etc/gtk-2.0/gtkrc:/home/rworkman/.gtkrc-2.0 GTK_RC_FILES=/etc/gtk/gtkrc:/home/rworkman/.gtkrc::/home/rworkman/.kde/share/config/gtkrc
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Oh wow, I don't even recall filing this bug, and even worse, reading what I wrote doesn't jog my memory. I don't see any evidence that the GTK2_RC_FILES edit to our profile scripts is still present, and I've not seen any recent reports of anything even remotely resembling this problem, so I'm going to go out on a limb here and say that it's safe to close this one as invalid now.
Changing status back to "Reported" ; sorry for the oversight in not doing it with my first reply...
Thanks for the update!