Bug 257331 - Suboptimal handling of GTK2_RC_FILES in krdb
Summary: Suboptimal handling of GTK2_RC_FILES in krdb
Status: RESOLVED WORKSFORME
Alias: None
Product: systemsettings
Classification: Applications
Component: krdb (other bugs)
Version First Reported In: unspecified
Platform: Slackware Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-19 16:06 UTC by Robby Workman
Modified: 2018-11-05 14:00 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robby Workman 2010-11-19 16:06:49 UTC
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
Comment 1 Robby Workman 2010-11-19 21:55:25 UTC
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
Comment 2 Andrew Crouthamel 2018-11-05 03:17:15 UTC
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!
Comment 3 Robby Workman 2018-11-05 06:29:08 UTC
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.
Comment 4 Robby Workman 2018-11-05 06:30:51 UTC
Changing status back to "Reported" ; sorry for the oversight in not doing it with my first reply...
Comment 5 Andrew Crouthamel 2018-11-05 14:00:06 UTC
Thanks for the update!