Strange bug in QSvgRenderer and KDE

[Albert Astals Cid]

On Friday 06 July 2007 13:05:24 Chusslove Illich wrote:
> > [: 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.

So any idea how to check user has not a LC_ALL set and warn him?

> 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?

No, KApplication constructor crashes if you don't do it afair.

> If yes, then the setlocale call should be made somewhere where no KDE app
> can circumvent it.

Albert