Re: converting string between gui widgets and octave

[Torsten]

On 12.10.2013 15:02, John W. Eaton wrote:
> On 10/12/2013 03:18 AM, Torsten wrote:
>> Some months ago I added changesets for converting strings into the
>> correct charsets between gui widgets like history/file browser and
>> octave itself. These conversions have disappeared leading to bug #40239.
>> One changeset where the conversion was removed (in that case for the
>> octave directory) seems to be 919796a440c6:
>> http://hg.savannah.gnu.org/hgweb/octave/rev/919796a440c6#l4.37
>> http://hg.savannah.gnu.org/hgweb/octave/rev/919796a440c6#l4.58
>> Was this intended?
> 
> I removed the call to toUtf8 because I wasn't sure why it was needed
> and we don't use it anywhere else in Octave.  Everything else is just
> using toStdString.
> 
> If that was a mistake, then please revert it, but can you also please
> explain when and why we should be using toUtf8?  I believe that Matlab
> uses 16-bit characters, so for compatibility Octave will probably have
> to support some kind of wide characters in the future.  Will we have
> to change this again?

>From the qt documentation, the default encoding of a QString is Latin-1:
http://qt-project.org/doc/qt-4.8/qtextcodec.html#setCodecForCStrings

  void QTextCodec::setCodecForCStrings ( QTextCodec * codec ) [static]
  Sets the codec used by QString to convert to and from
  const char * and QByteArrays. If the codec is 0 (the default),
  QString assumes Latin-1.

If those strings have special characters (ä,ü,è,...) not contained in
the first 128 ascii chars they are not correctly interpreted by octave
(which seems to use utf8). But instead of using toUtf8 and fromUtf8 each
time we transfer strings from qt to octave or vice versa, setting once
the general codec for QStrings with setCodecForCStrings is the
preferable way.

Torsten