Bug 186038

Clarification, I believe the bug was introduced in the transition from 4.2.0 to 4.2.1. I am almost sure of this because I have many of those paths on my hdd and I didn't have any problem until now. 

Unfortunately I don't know any way of downgrading to 4.2.0 now that 4.2.1 is default in the repositories, so I cannot 100% confirm this.

I can confirm that the bug *doesn't* happen with KDE 4.2.0 (Kubuntu). I'm updating to KDE 4.2.1 at the moment, so I'll try again once the update is done.

I can't reproduce the bug after upgrading to KDE 4.2.1. (Kubuntu packages)
It may be that I'm "lucky".

It seems a Qt issue.
Same kdelibs with Qt 4.4 works and with Qt 4.5 doesn't work.

why it works on Kubuntu ?
I guess KDE 4.2.1 is rebuilt against Qt 4.5, Debian packages aren't.

True, it is a Qt 4.5 problem.
Someone at Debian bugs (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518062) also told me that.
Indeed, after downgrading (dpkg abuse) to 4.4 this was solved.

I Consider it Debian bug and close for the moment.

I have the same bug in Fedora 10
kde 4.2.1
qt 4.5

This bug isn't Debian's fault. The commandline test case is. After using the commandline test case, one must try to save the file for the bug to become apparent. Just opening it isn't enough.

This was a Qt-4.5 regression, which affected kde-4.2.0. We fixed this, but just after 4.2.1. (Rev r934640).

So I confirm: 
Qt-4.4 + KDE-4.2.* = no problem. 
Qt-4.5 + KDE-4.2.0 or 4.2.1 (*) = this bug.
Qt-4.5 + KDE >= 4.2.2 = fixed.

(*) some distros (like Mandriva) integrated the fix into their 4.2.1 packages though.

Everyone: you should expect problems if you use Qt-4.5 with KDE-4.2.0 (and still a few with 4.2.1). This isn't the version of Qt that was meant to be used with KDE-4.2 (it didn't even exist when 4.2.0 came out).

*** Bug 186246 has been marked as a duplicate of this bug. ***

*** Bug 186386 has been marked as a duplicate of this bug. ***

(In reply to comment #10)
> This was a Qt-4.5 regression, which affected kde-4.2.0. We fixed this, but just
> after 4.2.1. (Rev r934640).
> 
> So I confirm: 
> Qt-4.4 + KDE-4.2.* = no problem. 
> Qt-4.5 + KDE-4.2.0 or 4.2.1 (*) = this bug.
> Qt-4.5 + KDE >= 4.2.2 = fixed.
> 
> (*) some distros (like Mandriva) integrated the fix into their 4.2.1 packages
> though.

I applied the patch and kwrite and okular works correctly now, but I still have an issue with gwenview. Maybe gwenview issue.

> 
> Everyone: you should expect problems if you use Qt-4.5 with KDE-4.2.0 (and
> still a few with 4.2.1). This isn't the version of Qt that was meant to be used
> with KDE-4.2 (it didn't even exist when 4.2.0 came out).

Yes, but even it works much better.
BTW, this bug come with 4.5.0 release. 4.5.0_rc1 had not this problem.

*** Bug 186481 has been marked as a duplicate of this bug. ***

*** Bug 186514 has been marked as a duplicate of this bug. ***

*** Bug 186572 has been marked as a duplicate of this bug. ***

*** Bug 186701 has been marked as a duplicate of this bug. ***

*** Bug 186728 has been marked as a duplicate of this bug. ***

*** Bug 186760 has been marked as a duplicate of this bug. ***

With the patch backported to 4.2.1, text files work now (Kate/Kwrite), but Gwenview is still bugged.  It can't open images containing non-latin characters.

On another note, a user reported that building Qt without support for the iconv library fixes the problem.

Reopening due to cases like gwenview (I guess there are others).

Created attachment 32007 [details]
Possible fix for gwenview

Does this patch fix gwenview? Thanks for testing.

*** Bug 186798 has been marked as a duplicate of this bug. ***

*** Bug 186793 has been marked as a duplicate of this bug. ***

(In reply to comment #23)
> Created an attachment (id=32007) [details]
> Possible fix for gwenview
> 
> Does this patch fix gwenview? Thanks for testing.

Works correctly on Gentoo with gwenview from KDE 4.2.1.
Thanks for the patch.

Ah. But wait. Wrong patch.
It all works here in trunk without a gwenview-specific patch, but with a Qt-4.5-final patch in klocale (r934710) to make sure kdecore initializes the locale properly.
Let's see about backporting that one....
Yep, doable, as long as nobody uses 4.5-rc1, but only 4.4.x or 4.5.0.
Sorry, you get to test again ;)
  http://www.davidfaure.fr/kde/kcatalog.cpp.diff
(patch for kdelibs/kdecore/localization/kcatalog.cpp)
Don't forget to remove the gwenview-specific hack too. Thanks!

Gentoo, x86_64, kde-4.2.1

Ok, for me with Russian charset utf8:
1. Recompile Qt with USE="-iconv" (kdelibs-4.2.1 without patch) and no
problems.
2. Upgrade to kdelibs-4.2.1-r1 (with patch for Gentoo, Qt with USE="-iconv") - no problems.
3. Recompile Qt with USE="+iconv" (kdelibs-4.2.1-r1) - Gwenview fail. :(
The latest patch (kcatalog.cpp.diff) I am not testing.
I returned to Qt with USE="-iconv".

Any testing that doesn't include the last patch is not really useful though, it's just a confirmation of what was already said and debugged before.

Hi,
I just tested kdelibs patched by the two patches above and without the gwenview patch applied. Can confirm that kwrite, okular and gwenview works correctly.

Also retest with this patches. Dolphin and Konqueror sent the names correctly, but in systemsettings encoding not fixed

(In reply to comment #31)
> Also retest with this patches. Dolphin and Konqueror sent the names correctly,
> but in systemsettings encoding not fixed

Do you mean the title after systemsetting start?

Created attachment 32033 [details]
System setting incorrect title after start.

It fix when click on the Advanced tab.

SVN commit 938370 by dfaure:

Backport the encoding fix for Qt-4.5.0 (r934710), adding a #if QT_VERSION >= 0x040500.
This breaks compilation with 4.5-rc1, but you're not supposed to use that anyway.
BUG: 186038


 M  +22 -7     kcatalog.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=938370

yes< my result after start in 31999

(id=31999)

http://bugs.kde.org/attachment.cgi?id=31999 here is my issue (russian locale)

Using KDE 4.2.1 with Qt 4.5.0 and the patches from commit 934640 and 938370 seems to solve the filename issue.

However, e.g. kdialog still has problems with utf8:

"kdialog --sorry äöüß" results in "äöüÃ"

"kdialog --sorry $(echo äöüß | iconv -f utf8 -t latin1)" in contrast does give the expected result.

What about russian symbols? I remove patches:( And cannot retest it:( And can someone post this bug in QT bugziila?

SVN commit 938657 by dfaure:

Fix encoding bug, "kdialog --sorry ?\195?\169" or "kmail --subject ?\195?\169" would double-encode the chars, due to a bad QByteArray-to-QString conversion (regression from r931769). Fix will be in 4.2.2.
CCBUG: 186038


 M  +1 -1      kcmdlineargs.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=938657

Konstantin: 1) please calm down. 2) é or russian characters make no difference, same bug and same fix. 3) no need to bug Qt, the bug was in KDE, even though it came from a behavior change in Qt (and the last KCmdLineArgs fix was definitely a KDE bug); I discussed the matter with the involved Qt developer already.
Anyway, all fixed for 4.2.2.

Sorry. Very thanks for paths. After 4.2.2 I no more need to use GNOME

*** Bug 186930 has been marked as a duplicate of this bug. ***

You can also use File / Open meanwhile, no reason to switch to another desktop environment :-)

*** Bug 187148 has been marked as a duplicate of this bug. ***

*** Bug 187437 has been marked as a duplicate of this bug. ***

*** Bug 187470 has been marked as a duplicate of this bug. ***

*** Bug 187768 has been marked as a duplicate of this bug. ***

I still have two issues with this wierd Qt 4.5 regression...
I use greek locale on my system, hence the following problems:

1) $kdeapp --help outputs the help text using questionmarks instead of greek symbols... :P
2) drkonqi has problem getting the name of the crashed application. For example, "Plasma desktop" is translated as "Χώρος εργασίας Plasma" and in drkonqi it appears as "ΧÏÏÎ¿Ï ÎµÏγαÏÎ¯Î±Ï Plasma".

testcase: $(kde4-config --path libexec)/drkonqi --signal 11 --appname plasma --appversion 1.0 --bugaddress submit@bugs.kde.org --programname "Χώρος εργασίας Plasma" --pid 0

For drkonqi, the problem seems to be that argument parsing and conversion to QString happens before QApplication is constructed (and I have changed this in the work branch of drkonqi), but I don't understand why should this be required now if it used to work with Qt 4.4...

George: your testcase works fine for me, in both 4.2-branch and trunk. You didn't mention which version of kdelibs you were using...

*** Bug 188012 has been marked as a duplicate of this bug. ***

(In reply to comment #50)
> George: your testcase works fine for me, in both 4.2-branch and trunk. You
> didn't mention which version of kdelibs you were using...

Ok sorry, it was my fault. I am using the debian 4.2.1 packages, which include the patches that you made on the 4.2 branch, however it seems that kdelibs needs to be rebuilt with Qt 4.5 in order to work properly. Rebuilding the package fixes the problem for me. I can't say I like this solution, but I guess I'll have to live with it...

*** Bug 188052 has been marked as a duplicate of this bug. ***

*** Bug 185222 has been marked as a duplicate of this bug. ***

*** Bug 184261 has been marked as a duplicate of this bug. ***

kde 4.2.2 Suse factory. Gwenview could not open file with non latin symbols in the path. The bug is not fixed.

Olegator: Qt version?

And more tricky question: which Qt version was kdelibs compiled against....
Compiling against Qt-4.4 and then upgrading to Qt-4.5 won't work, the fix is done at compile time if Qt-4.5 is detected...

(In reply to comment #57)
> Olegator: Qt version?
> 
> And more tricky question: which Qt version was kdelibs compiled against....
> Compiling against Qt-4.4 and then upgrading to Qt-4.5 won't work, the fix is
> done at compile time if Qt-4.5 is detected...

Qt 4.5.0-43.1. But I do not know as the package has been compiled in the Suse Factory repository. Thanks.

I have som issue also in Ark with non-latin UTF-8 characters (KDE 4.2.2 QT 4.5). See bug 187201. I think this is not fixed part of this

I can confirm that bug is still not fixed fully in 4.2.2, at least in openSUSE builds.
Kwrite and Okular now open files OK for me, but the file with non-English characters in its name still can't be opened with Gwenview and dragging-n-dropping of such a file to KMail message window doesn't work either (manual opening and attaching in Gwenview and KMail respectively still works via main menu or toolbar items).

KDE 4.2.2/Qt 4.5.0 on Gentoo without patches from 4.2.1 works correctly.

No problem with kate, gwenview.

(In reply to comment #60)
> dragging-n-dropping of such a file to KMail message window doesn't work either

I just tested. No problem to DnD file "hlavička.png" to gwenview.

openSUSE person reporting:

This bug is a problem with openSUSE < 11.2 (Factory) and KDE 4.2.x packages only when Qt 4.5 is installed. 

This is because the extra initialisation added by David in 938370 is only used if the packages are built with Qt 4.5.  Our 11.1 and earlier packages are built with and intended for use with Qt 4.4, so when the KDE:Qt repo to get Qt 4.5, the initialisation does not take place.

I've just added a patch to our 4.2.2 packages that performs the version check at runtime.

Created attachment 32572 [details]
linux-specific qt version check

In case anyone else wants this.

Nice fix, thanks Will!  (Can you inform kde-packager about this fix?)

The bug was corrected after a last update from opensuse 11.1 factory

*** Bug 187855 has been marked as a duplicate of this bug. ***

*** Bug 188746 has been marked as a duplicate of this bug. ***

*** Bug 188369 has been marked as a duplicate of this bug. ***

*** Bug 167458 has been marked as a duplicate of this bug. ***

hi.
i'm a little bit lost with the opensuse stuff. For those not using opensuse, is it fixed ? in which version of kde ? Will 4.2.3 have it ?

In openSUSE it's fixed in our 4.2 repositories (KDE:42, KDE:KDE4:Factory and openSUSE:Factory) so that it works if you install Qt 4.5 with KDE packages built with Qt 4.4.  The mail was forwarded onto the packagers' mailing list but there wasn't any discussion which distros have integrated it.  If KDE 4.2.3 packages are built with Qt 4.5 and run with Qt 4.5 there won't be an issue.

It's fixed also on Debian packages (KDE 4.2.2-1)