[Kde-bindings] Utf-8 bug

[Richard Dale]

On Thursday 19 January 2006 13:55, Han Holl wrote:
> On Thursday 19 January 2006 11:29, Richard Dale wrote:
> > Well, I've just tried it and it works fine for me. I added a $KCODE = 'u'
> > line, and commented out the call to the dcop command line tool as that
> > isn't to do with korundum:
>
> Thanks a lot for your efforts.
> With the $KCODE='u' it now works for me as well. And I don't quite
> understand why.
> I can understand that encoding make a difference for doing things with
> strings, but in the case of a pathname I would expect it to be passed as
> is. (Ok, the code _might_ just check for binary zero bytes, but that's
> about it.)
>
> I'm allowed to pass all kinds of binary information in Ruby strings. I've
> written lots of scripts that traverse directories like this, without ever
> to have to use $KCODE.
> There seems to be lurking somewhere something with an idea of 'valid
> pathname' that's not the same as the OSes idea of valid pathname.
> Let's assume I read pathnames from a file: how am I supposed to know which
> encoding to use? My script is supposed to run on any filesystem,
> independent of encoding.
>
> I still consider this a bug.
No it's correct! The value of $KCODE affects how ruby strings are converted to 
and from QStrings. QStrings are always unicode, so you can guarantee that Qt 
code will run on any filesystem, as long as you only use calls in the Qt api 
to access it. If you don't set $KCODE to 'u', all strings are assumed to be 
latin1, which is going to be locale specific and not always portable.

In this line, the ruby string will be converted to a QString, and the 
conversion will vary according to the value of $KCODE:

dk.setWallpaper(file, 4)

Without $KCODE set, the unicode pair for umlaut will be converted to two 
seperate chars in the QString.

-- Richard