Bug 327919 - GTK style doesn't work if user's home directory contains non-ASCII character(s)
Summary: GTK style doesn't work if user's home directory contains non-ASCII character(s)
Status: RESOLVED FIXED
Alias: None
Product: systemsettings
Classification: Unclassified
Component: krdb (show other bugs)
Version: 4.11.3
Platform: Archlinux Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-21 21:39 UTC by Dāvis
Modified: 2013-12-02 10:45 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.11.5


Attachments
GTK stlye doesn't work, /home/Dāvis/ (.gtkrc-2.0 exists) (249.17 KB, application/octet-stream)
2013-11-29 22:58 UTC, Dāvis
Details
GTK stlye does work, /home/test/ (.gtkrc-2.0 doesn't exist) (669.00 KB, application/octet-stream)
2013-11-29 22:59 UTC, Dāvis
Details
GTK stlye does work, /home/test/ (.gtkrc-2.0 exists) (676.00 KB, application/octet-stream)
2013-11-29 23:00 UTC, Dāvis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dāvis 2013-11-21 21:39:47 UTC
GTK applications doesn't use respective GTK style if user's home directory contains non-ASCII character(s). For example Firefox will look http://i.imm.io/1kBNU.png for user with home directory as tēst


Reproducible: Didn't try

Steps to Reproduce:
1. Make sure oxygen-gtk2/oxygen-gtk3  and  kde-gtk-config is installed
2. Install GTK application such as Firefox
3. Select Oxygen style in System Settings > Application Appearance > Style and GTK Configuration
3. Create new user with home directory such as /home/tēst/
4. Log in as previously created user
5. Run GTK app (eg. Firefox)
Actual Results:  
GTK application wont be launched with appropriate theme/style but with some other not so good looking style. For Firefox it looks http://i.imm.io/1kBNU.png

Expected Results:  
GTK application should use chosen GTK style (eg. Oxygen).
Comment 1 Hugo Pereira Da Costa 2013-11-22 14:40:31 UTC
Must be an font encoding issue. Will check.
Comment 2 Yichao Yu 2013-11-22 16:19:26 UTC
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...).
Comment 3 Yichao Yu 2013-11-22 16:32:57 UTC
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.
Comment 4 Dāvis 2013-11-22 18:06:49 UTC
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
Comment 5 Dāvis 2013-11-22 18:23:44 UTC
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
Comment 6 Yichao Yu 2013-11-22 18:33:59 UTC
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
Comment 7 Dāvis 2013-11-22 19:10:24 UTC
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
Comment 8 Hugo Pereira Da Costa 2013-11-28 14:10:54 UTC
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)
Comment 9 Yichao Yu 2013-11-28 14:17:22 UTC
Maybe you mean `$HOME/.gtkrc-2.0` ?
Comment 10 Hugo Pereira Da Costa 2013-11-28 14:18:09 UTC
yes that's what I mean (or any file of the same type.)
Comment 11 Dāvis 2013-11-28 17:43:17 UTC
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.
Comment 12 Yichao Yu 2013-11-28 17:55:42 UTC
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.
Comment 13 Ruslan Kabatsayev 2013-11-28 19:10:33 UTC
Does running the application as this make it use oxygen theme:

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

?
Comment 14 Dāvis 2013-11-28 19:17:59 UTC
Yes, then it correctly uses GTK Oxygen theme. So I guess I should submit bug at GTK project.
Comment 15 Dāvis 2013-11-28 20:34:59 UTC
I create this bug at GNOME bugzilla https://bugzilla.gnome.org/show_bug.cgi?id=719513
Comment 16 Hugo Pereira Da Costa 2013-11-28 20:55:05 UTC
@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 ...
Comment 17 Dāvis 2013-11-29 02:44:59 UTC
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...
Comment 18 Yichao Yu 2013-11-29 03:32:24 UTC
... 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)?
Comment 19 Hugo Pereira Da Costa 2013-11-29 12:23:14 UTC
@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.
Comment 20 Dāvis 2013-11-29 22:56:32 UTC
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.
Comment 21 Dāvis 2013-11-29 22:58:39 UTC
Created attachment 83832 [details]
GTK stlye doesn't work, /home/Dāvis/ (.gtkrc-2.0 exists)
Comment 22 Dāvis 2013-11-29 22:59:30 UTC
Created attachment 83833 [details]
GTK stlye does work, /home/test/ (.gtkrc-2.0 doesn't exist)
Comment 23 Dāvis 2013-11-29 23:00:22 UTC
Created attachment 83834 [details]
GTK stlye does work, /home/test/ (.gtkrc-2.0 exists)
Comment 24 Yichao Yu 2013-11-29 23:10:13 UTC
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.
Comment 25 Yichao Yu 2013-11-29 23:12:55 UTC
(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....
Comment 26 Dāvis 2013-11-29 23:19:47 UTC
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?
Comment 27 Dāvis 2013-11-29 23:26:14 UTC
(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
Comment 28 Yichao Yu 2013-11-29 23:34:23 UTC
Looks like it is krdb.cpp::applyGtkStyles
Comment 29 Dāvis 2013-11-29 23:57:37 UTC
(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
Comment 30 Yichao Yu 2013-11-30 00:00:08 UTC
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.
Comment 31 Yichao Yu 2013-11-30 00:01:47 UTC
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)?
Comment 32 Yichao Yu 2013-11-30 00:04:37 UTC
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
Comment 33 Dāvis 2013-11-30 00:05:25 UTC
(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.
Comment 34 Yichao Yu 2013-11-30 00:11:51 UTC
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
Comment 35 Dāvis 2013-11-30 03:34:38 UTC
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.
Comment 36 Dāvis 2013-11-30 03:39:36 UTC
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.
Comment 37 Yichao Yu 2013-11-30 04:36:48 UTC
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
Comment 38 Yichao Yu 2013-11-30 04:37:41 UTC
And it will be very nice if someone can reassign this to kde-workspace ....
Comment 39 Dāvis 2013-11-30 19:49:38 UTC
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.
Comment 40 Yichao Yu 2013-11-30 19:54:43 UTC
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).
Comment 41 Yichao Yu 2013-11-30 19:55:44 UTC
https://git.reviewboard.kde.org/r/114219/
Comment 42 Martin Flöser 2013-12-02 07:27:42 UTC
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