"Daniel P. Berrange" <berra...@redhat.com> writes: > On Wed, Aug 26, 2015 at 11:13:00AM +0200, Alberto Garcia wrote: >> On Tue 25 Aug 2015 09:54:42 AM CEST, Markus Armbruster wrote: >> >> >> (D) Run in a controlled mixed locale >> >> GTK runs completely in the locale determined by setlocale() (since it >> >> never has to display raw JSON) >> >> We fix our JSON output code to use thread-specific locale >> >> manipulations to (temporarily) switch to C locale before printing JSON >> >> >> >> that way, GTK still shows full German formatting for any localized >> >> message in the GUI that happens to print numbers, but the JSON output >> >> (which is independent of the GUI) also behaves correctly as a C-only >> >> entity. >> > >> > Switching back to C locale whenever some unwanted locale-dependency >> > breaks the code is problematic, because it involves finding all the >> > places that break, iteratively (euphemism for "we debug one breakage >> > after the other, adding temporary locale switches as we go). >> >> For some cases we probably don't even need to switch the locale. For the >> JSON case cannot we just easily convert the QFloat into a string >> ourselves without using printf's "%f" ? > > FWIW, libvirt had this exact same problem with formatting doubles for > JSON while non-C locales are in effect. We used the glibc thread-local > locale support, and fallback to some sick string munging in non-glibc > case: [...]
For QEMU, I doubt sick string munging just to support GUI localization on losing systems is worthwhile. >> That doesn't invalidate however your point. >> >> > I'd feel much better about confining GTK in its own thread, and >> > setting only that thread's locale. >> >> I haven't digged much into that part of the QEMU code, but if my >> assumptions are true I think we would need at least: >> >> - A separate GMainContext with its own main loop >> - Making sure that all the code that touches the UI runs from that >> thread. >> >> This is in principle possible, but I fear that we might be opening a can >> of worms. > > Agreed, my experiance is that you should always run GTK in the main > thread and never try todo anything more clever with threads + GTK. > It has always ended in tears for me - even if you think you have it > working on your system, you'll inevitably find a different version > of GTK where it has broken. It just isn't worth the pain to try to > run anything GTK related in a non-main thread. If we can't move GTK out of the main thread, we need to move everything else out. One more option: instead of switching back to the C locale around identified troublemakers (and then chase them down one by one, bug by bug), switch away from it just around the GUI. Thread-locally of course. Callbacks may require extra care. We should've stayed out of the GUI business.
