[Pkg-electronics-devel] Bug#567585: Bug#567585

[Peter Clifton]

On Thu, 2010-02-04 at 17:30 +0000, ahornbridge at yahoo.co.in wrote:
> Peter Clifton sandte am 04.02.10 14:38 Uhr:
> > It isn't present in Ubuntu.
> > 
> > I don't think this is something we'll be able to fix easily. I can't
> > find any setlocale() calls in the gtk-qt-engine source, so I presume it
> > is "somewhere" in QT which resets the locale based upon the environment
> > variables.
> > 
> > I guess we "could" attempt to work around it by re-setting the
> > LC_NUMERIC environment variable when loading gschem, hopefully
> > discouraging QT from messing up the setting afterwards..
> > 
> > Since this isn't a common use-case, so is unlikely to be a huge priority
> > to fix / work around. In the long term, I'd love to see gschem stop
> > relying on setting LC_NUMERIC in the first place.
> 
> Nevermind, as I had included gtk-gt-engine by accident anyway.
> It is an peculiar error none the less. At least I now know how to circumvent
> the error, what makes gschem not totally unusable for me.
> 
> Thanks!

I'm guessing gtk-qt-engine fires up Qt-core on load, which does this:

    setlocale(LC_ALL, "");                // use correct char set mapping

I'd "imagine", that since the engine fires up after our initial locale
setup, this messes up our own setting of LC_NUMERIC.

I can't think of how we would provoke a call-back once the GTK theme
engine has loaded to change it back though.

Perhaps we could introduce code to check / reset the locale before we
end up relying on LC_NUMERIC in the printing code.