Strange bug in QSvgRenderer and KDE

[Chusslove Illich]

> [: Albert Astals Cid :]
> [...] it would seem maybe there was some change in Qt that broke it
> recently?
> [...]
> Should we ensure everyone defines its LC_ALL correctly?

I was faced with the similar problem recently, whereupon I found this
comment in the Qt's src/corelib/codecs/qtextcodec.cpp:

  /*!
      Returns a pointer to the codec most suitable for this locale.

      On Windows, the codec will be based on a system locale. On Unix
      systems, starting with Qt 4.2, the codec will be using the \e
      iconv library. Note that in both cases the codec's name will be
      "System".
  */

In other words, since 4.2, Qt relinquishes locale handling to iconv, and
iconv requires the setlocale(LC_ALL, "") call to be made in order to get
locale from user environment variables, or else it defaults to POSIX, which
is non-UTF8. If the call is made, but the user environment doesn't define
locale, it also falls back to POSIX.

So, yes, we should ensure that everyone has LC_ALL set correctly (for "non-
localized" environments, that would mean en_US.UTF-8). IMO, it is good that
now KDE too will trip on this, as users in 21st century really, really need
to have their system set up to UTF-8. I think that some distributions even
make LC_ALL=en_US.UTF-8 default unless changed by the user.

As for the setlocale(LC_ALL, "") call in the KDE apps, currently it is being
made by KCmdLineArgs::init(), and by KCatalog upon first found translated
message. Are apps allowed not to make KCmdLineArgs::init() call? If yes,
then the setlocale call should be made somewhere where no KDE app can
circumvent it.

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070706/e0c2ac41/attachment.sig>