[PyQt] PyKDE dcopext string marshalling; no unicode chars in a QString?

[Mark Summerfield]

On Mon 30-Apr-07, Danny Pansters wrote:
> On Monday 30 April 2007 16:46:59 you wrote:
> > > It seems I can't retrieve a QString object containing non-ASCII
> > > characters.
> >
> > You can if you use unicode() instead of str().
>
> Yes that's obvious, but it may break other people's apps when using such a
> patched dcopext module. I create and maintain the pyqt/pykde packages for
> FBSD and I think people would not be amused if I decided to break the
> expected behaviour (even if it's wrong) just to make my stuff work "the way
> it ought to".
>
> For private use patching dcopext would do fine I guess, I only want to use
> it for prototyping at this point. I was thinking that maybe using QString
> datatype for this purpose was be a bad choice to begin with.
>
> Is this a known bug or not deemed a problem?

I think there are some gotchas regarding using QStrings where str or
unicode are expected.

If you have a _string_ with non-ASCII then you either need to end up
with a unicode or use a codec to produce an 8-bit str, e.g., using
latin1. If you have _bytes_ then you could use QByteArray and convert
that to str without using an encoding, but then there's no way of
knowing what those bytes really mean. Since you are processing
framebuffer data which I assume is just a char* of raw bytes then using
a QByteArray and converting that to a str seems like the way to go.


-- 
Mark Summerfield, Qtrac Ltd., www.qtrac.eu