Bug 327919

Must be an font encoding issue. Will check.

1. Can you reproduce the problem with other gtk themes (If you can, it shouldn't be a bug of oxygen-gtk)?
2. Could you paste your ~/.gtkrc-2.0?
3. In your steps to reproduce, you set the gtk styles before creating the new use. This will not work for sure. Is this what you actually do or do you mean the reverse order.

For me, it is really unlikely a bug of oxygen-gtk since it is not loaded at all (unless oxygen-gtk refuses to initialize when failing to write to a user's home, which is another bug that should be fixed...).

I have just tested on a ssh forward session with kde-gtk-config 2.2.1, oxygen-gtk2 1.4.0 and a home directory with Chinese in it (with the right order in the steps or reproduce) and it works fine.

I have noticed that the tab name of kde-gtk-config is "GTK" instead of "Style and GTK Configuration" and AFAIK kde-gtk-config is the (only?) kcm gtk-config module currently maintained. Which kcm module are you using (`kcmshell --list | grep -i gtk` may help you figure that out). Maybe it is a bug in the kcm module you are using to configure gtk theme.

Yes, any GTK theme doesn't work.

There's no difference for ~/.gtkrc-2.0 between user with home dir test and tēst, http://pastebin.com/9iNYe0j0

Actually setting style is not required at all. When creating new user there's no ~/.gtkrc-2.0 but for one oxygen-gtk is used while for other not.

With that I meant Oxygen for "System Settings > Application Appearance > Style" and oxygen-gtk for "System Settings > Application Appearance > GTK". Now I checked that Style doesn't matter at all.

`kcmshell --list | grep -i gtk` gives kde-gtk-config

I've up-to-date Arch Linux
* gtk-engines 2.21.0-1
* gtk-update-icon-cache 2.24.22-1
* gtk2 2.24.22-1
* gtk3 3.10.4-1
* kde-gtk-config 2.2.1-1
* kdebase-lib 4.11.3-1
* kdebase-plasma 4.11.3-1
* kdebase-runtime 4.11.3-1
* kdebase-workspace 4.11.3-1
* kdelibs 4.11.3-1
* oxygen-gtk2 1.4.0-1
* oxygen-gtk3 1.2.0-1
* webkitgtk2 1.10.2-8
* wxgtk 2.8.12.1-5


There's difference for ~/.kde4/share/config/gtkrc-2.0 between user with test and tēst

for user with home dir as /home/test/ => http://pastebin.com/NHpJifR4 and for /home/tēst/ http://pastebin.com/CGeRiEGQ

Actually no, that just was some old gtkrc-2.0 for /home/test/, now when I deleted it, it's recreated same as for /home/tēst/

Basically configuration doesn't matter, it's just not used for /home/tēst/ at all

Actually I'm also using ArchLinux here.

So your problem is your ~/.gtkrc-2.0 is just not used at all? (that looks VERY strange and doesn't looks like that it is related to KDE at all)

Maybe you can use either `gtk-chtheme` or `gtk-theme-switch2` to set a non-KDE gtk theme. If it doesn't work either, I would say it is not a KDE bug ....

BTW, do you have any gnome daemon running in the background? I think it can sometimes override what's in .gtkrc-2.0. Also, I remember there is a xsettings package for KDE (haven't used and not sure if it is maintained) which may do the same thing as well. A quick google gives me this[1]. Maybe you can check whether you have that installed and running?

[1] https://forum.kde.org/viewtopic.php?f=225&t=102229

I don't know if it is used or not, but fact is that GTK stlye doesn't work for /home/tēst/ but does work for /home/test/ even if  both directories contain same data.

Tried with both `gtk-chtheme` and `gtk-theme-switch2`, but it didn't gave any effect.

I've no idea which packages bug it is. But KDE seemed best bet.

Nope, I don't have any xsettings installed. Running processes http://pastebin.com/uTuSne6Q

1/ this bug has nothing to do with oxygen
2/ please post the content of new users $HOME/.gtkrc
3/ does this file change whenever you change the style (by whatever mean), from your new user directory ? 
4/ does the application's appearance change when you modify the file manually (to select another style)

Maybe you mean `$HOME/.gtkrc-2.0` ?

yes that's what I mean (or any file of the same type.)

I didn't marked this as Oxygen's bug, that was done by Christoph Feck.

When I create new user and login as it, there isn't any ~/.gtkrc* but GTK Oxygen theme is used for `/home/test` but not for `/home/tēst`
When I change GTK style then `~/.gtkrc-2.0` and `~/.gtkrc-2.0-kde` (it's symlink to .gtkrc-2.0) is created and content is correct for respective style. I already previously posted content of it http://pastebin.com/9iNYe0j0 and it's same for both home dirs.

Changing GTK theme, `~/.gtkrc-2.0` is correctly updated.

So seems whichever package/library reads `~/.gtkrc-2.0` doesn't do it for `/home/tēst` as it have no effect. But it's same even if `~/.gtkrc-2.0` doesn't exist.

The library that reads ~/.gtkrc-2.0 is gtk2.
As I said, if you cannot use a gtk tool (e.g. gtk-chtheme or gtk-switch-theme2) or ~/.gtkrc-2.0 to set the theme for gtk2 application, it doesn't sound like related to KDE at all.

Does running the application as this make it use oxygen theme:

GTK2_RC_FILES=/usr/share/themes/oxygen-gtk/gtk-2.0/gtkrc appname

?

Yes, then it correctly uses GTK Oxygen theme. So I guess I should submit bug at GTK project.

I create this bug at GNOME bugzilla https://bugzilla.gnome.org/show_bug.cgi?id=719513

@Davis,
thanks for the details, and sorry if I sounded aggressive in anyway. 
reporting to gnome is the right thing to do indeed: gtk is the library supposed to read .gtkrc-2.0
Now, to make sure KDE is off the hook:
can you reproduce with a different desktop environment, such as xfce (or another lightweight) ? 

Finally, there is also the possibiliy that there is an issue with your system, such as some encoding mismatch between what gtk expect and what your system use. Something like that ... 
But I don't have much experience with such things ...

No worries and you didn't ;)

I tested Xfce, LXDE and GNOME and they all work fine with GTK apps so actually it is some KDE related bug.

I just removed all KDE packages, installed only kdebase-workspace and suddenly GTK style works fine* then when I installed kde group again, it doesn't work anymore. So seems there's some KDE package in kde group which causes this bug. Now I tried to remove kde packages in batches to see if something changes, but nope. I've removed everything  with kde in name and installed only kdebase-workspace again, but still GTK app style just doesn't work, while it perfectly works in any other DE when I logout and switch to them... It also works for users where home dir contains only ASCII chars.

I've no idea, but it seems some package that KDE uses, but not any other DE. Now I removed all DEs and just left kdebase-workspace, here's list of all currently installed packages: http://pastebin.com/ZREt7kjW and some must be causing it.

* -  or maybe I just thought it did...

... wierd ...
When only kde-workspace is installed, is gtk theme working or not?
Can you check if you have any environment variable set? You said when you create a new user (with only ascii in username) without any gtkrc files, the gtk applications automatically uses the oxygen theme. This is AFAIK not what I remember a few month ago.

What if you run `env -i DISPLAY=${DISPLAY} HOME=${HOME} gtk-demo`? Does the application use the right theme (set in .gtkrc-2.0)?

@Davis,
also, could you try use 
"strace oxygen-gtk"
in a case for which it works
and in a case for which it does not, 
and post the resulting logs here (as attachment) ? 
Just start the application and exit it right after. No need to have too long a log.

Yes GTK style works fine with `env -i DISPLAY=${DISPLAY} HOME=${HOME} gtk-demo`

I noticed that $GTK2_RC_FILES contains invalid encoding and so it's the real reason why GTK can't open ~/.gtkrc-2.0 as it's looking for it in wrong place.

Whatever sets $GTK2_RC_FILES, is doing it wrong. Here's all env http://pastebin.com/UgfsFMwN and can see that both $GTK_RC_FILES and $GTK2_RC_FILES have /home/DÄvis/ not how it should be /home/Dāvis/ like it is for $GS_LIB, $QT_PLUGIN_PATH, etc


I think you meant oxygen-gtk-demo? not oxygen-gtk as I don't have such app and neither it's in repository.

I run it 3 times, first when it doesn't work because of non-ASCII home dir, then 2 times with when it works. Once when there's no .gtkrc-2.0 in home and next when it's there. Will attach log in few mins.

Created attachment 83832 [details]
GTK stlye doesn't work, /home/Dāvis/ (.gtkrc-2.0 exists)

Created attachment 83833 [details]
GTK stlye does work, /home/test/ (.gtkrc-2.0 doesn't exist)

Created attachment 83834 [details]
GTK stlye does work, /home/test/ (.gtkrc-2.0 exists)

Can you remove kde-gtk-config and see if you still have the problem?
A grep in the source code suggests it might be the package that set this enviroment variable.

(In reply to comment #24)
> Can you remove kde-gtk-config and see if you still have the problem?
> A grep in the source code suggests it might be the package that set this
> enviroment variable.

Actually, I don't thing I have found the right one... But the process that set that variable is definitely the one to blame....

In strace can easily see it's using wrong encoding, #1178 line

lstat("/home/D\303\204\302\201vis/.gtkrc-2.0", 0x7fff708b6770) = -1 ENOENT (No such file or directory) 

vs

lstat("/home/test/.gtkrc-2.0", {st_mode=S_IFREG|0644, st_size=391, ...}) = 0


It should be

lstat("/home/D\304\201vis/.gtkrc-2.0", {st_mode=S_IFREG|0644, st_size=391, ...}) = 0

which it is when I change $GTK2_RC_FILES

Now question, where does $GTK2_RC_FILES come from?

(In reply to comment #25)
> (In reply to comment #24)
> > Can you remove kde-gtk-config and see if you still have the problem?
> > A grep in the source code suggests it might be the package that set this
> > enviroment variable.
> 
> Actually, I don't thing I have found the right one... But the process that
> set that variable is definitely the one to blame....

It's not kde-gtk-config, I uninstalled it, rebooted and it's still there

Looks like it is krdb.cpp::applyGtkStyles

(In reply to comment #28)
> Looks like it is krdb.cpp::applyGtkStyles

yeah, it's possible, wasn't good idea to use QLatin1String
https://projects.kde.org/projects/kde/kde-workspace/repository/revisions/master/entry/kcontrol/krdb/krdb.cpp#L92

And the bug is in line 101:
QString value = QFile::encodeName(list.join(":"));
where the return value of QFile::encodeName is a QByteArray, which use wrong encoding when casted implicitly to QString.
Change it to

QString value = list.join();

Fixes it for my small test case here.

Not really, the QLatin1String is fine, since the return value of sysGtkrc is guaranteed to be ASCII only.

Can you test if my fix above fixes your problem (may need to recompile kde-workspace)?

I'll submit a review request if this fix works.

patch:
From fa4c798f69c00895cd6f745994dd07d0fb75f0be Mon Sep 17 00:00:00 2001
From: Yichao Yu <yyc1992@gmail.com>
Date: Fri, 29 Nov 2013 19:03:50 -0500
Subject: [PATCH] Do not encode QString to QByteArray and cast it back to
 QString. This causes problem when there are Unicode characters in ${HOME}

---
 kcontrol/krdb/krdb.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kcontrol/krdb/krdb.cpp b/kcontrol/krdb/krdb.cpp
index 5da3fcb..f4df486 100644
--- a/kcontrol/krdb/krdb.cpp
+++ b/kcontrol/krdb/krdb.cpp
@@ -98,7 +98,7 @@ static void applyGtkStyles(bool active, int version)
 
    // Pass env. var to kdeinit.
    QString name = gtkEnvVar(version);
-   QString value = QFile::encodeName(list.join(":"));
+   QString value = list.join(":");
    org::kde::KLauncher klauncher(QStringLiteral("org.kde.klauncher5"), QStringLiteral("/KLauncher"), QDBusConnection::sessionBus());
    klauncher.setLaunchEnv(name, value);
 }
-- 
1.8.4.2

(In reply to comment #31)
> Not really, the QLatin1String is fine, since the return value of sysGtkrc is
> guaranteed to be ASCII only.
> 
> Can you test if my fix above fixes your problem (may need to recompile
> kde-workspace)?

yeah, I saw that when looked closer what is sysGtkrc


I'll test, just have to download source code.

Sorry, I was on master ... the patch for 4.11 should be

From 6b9982658679effd508eea8a01b8ff74c0c0aca2 Mon Sep 17 00:00:00 2001
From: Yichao Yu <yyc1992@gmail.com>
Date: Fri, 29 Nov 2013 19:03:50 -0500
Subject: [PATCH] Do not encode QString to QByteArray and cast it back to
 QString. This causes problem when there are Unicode characters in ${HOME}

---
 kcontrol/krdb/krdb.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kcontrol/krdb/krdb.cpp b/kcontrol/krdb/krdb.cpp
index 92d84e9..31e8820 100644
--- a/kcontrol/krdb/krdb.cpp
+++ b/kcontrol/krdb/krdb.cpp
@@ -99,7 +99,7 @@ static void applyGtkStyles(bool active, int version)
 
    // Pass env. var to kdeinit.
    QString name = gtkEnvVar(version);
-   QString value = QFile::encodeName(list.join(":"));
+   QString value = list.join(":");
    KToolInvocation::klauncher()->setLaunchEnv(name, value);
 }
 
-- 
1.8.4.2

You should have attached it as file :P For some reason Firefox couldn't copy line breaks and it all was single line. Anyway used Konqueror.

And .... Partial success!!! Patch works, but kde-gtk-config also needs to be patched.

When I install this patched kde-workspace, then there isn't any GTK_RC* and GTK style works but once I install kde-gtk-config and change GTK style then it's created with wrong encoding and GTK style doesn't work anymore.

By the way to compile kde-workspace I had to use cmake -DPYTHON_EXECUTABLE:FILEPATH=/usr/bin/python2 because on Arch Linux /usr/bin/python is py3

Also compiling was quite long even if it used all cores and there were quite a bit of warnings.

The review request is here[1] and you can grab whatever you want from there... ;-P

I don't think kde-gtk-config has anything to do with this (at least not with environment variables, the one I saw before was unrelated).

Are you sure you have had the right compile parameters? python executable is not the only one that is needed to make it work. If this is the first time you compiles kde-workspace, you'd better check archlinux's PKGBUILD[2] for the right compile options to use. Do you also have the right CMAKE_INSTALL_PREFIX? I have just tested it myself and confirmed that the enviroment variable has the right unicode in it now.

Also, if you are not compiling the package and just use `make; sudo make install`. You can cd to the subdirectory before make (after cmake). Compiling everything under kcontrol/ only takes 2-3 min on a 4-year-old dual cure laptop here, and even only compiling kcontrol/krdb/ may work.

[1] https://git.reviewboard.kde.org/r/114219/
[2] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/kdebase-workspace

And it will be very nice if someone can reassign this to kde-workspace ....

Earlier I was just doing cmake, make, make install and I guess something weren't installed properly as then I didn't had any GTK_RC* variables created and so it worked fine. Now I followed PKGBUILD steps and now there is $GTK2_RC_FILES with correct encoding and changing GTK style it's still correct. So yeah, patch works perfectly.

My guess is that you were missing CMAKE_INSTALL_PREFIX (default to /usr/local/ ....) and if that is the case, you might want to check if you have anything you don't want under /usr/local/ and remove them (they won't do anything bad except wasting space of your hard disk though).

https://git.reviewboard.kde.org/r/114219/

Git commit f10131de05ae979cdc7333f5ccfecbeb27265785 by Martin Gräßlin, on behalf of Yichao Yu.
Committed on 30/11/2013 at 00:03.
Pushed by graesslin into branch 'KDE/4.11'.

Do not encode QString to QByteArray and cast it back to QString

This causes problem when there are Unicode characters in ${HOME}

REVIEW: 114219
FIXED-IN: 4.11.5

M  +1    -1    kcontrol/krdb/krdb.cpp

http://commits.kde.org/kde-workspace/f10131de05ae979cdc7333f5ccfecbeb27265785