On Saturday, 2 November 2019 22:35:00 PST André Pönitz wrote: > Compiled opt-in per-application at least shifts the blame from Qt to the > application vendor, compiled opt-in per-process environment leaves the blame > still with the application vendor, but actually provides the possibility to > do the right thing when it is known that the child actually _needs_ it.
When the parent process written in Qt knows that the child needs it, they must already be using QProcessEnvironment. So when the user needed to do it, it's a bug in the Qt application. There are two scenarios: 1) when the child process needs en_US or C, because it was printing messages in another language, or far more commonly, it was using thousands and decimal separators other than those of English 2) when the child process needs a non-UTF-8 because it was confused by UTF-8 multibyteness or was using that to print “fancy quotes” The case (1) is not a problem if we override the environment to en_US.UTF-8 or C.UTF-8. Your scenario is restricted to case (2). Do note that forcing the environment today, in Qt 5, has implications for the Qt application itself. It's just wrong to do so and I think the number of people doing that is fairly small. With this proposal, in Qt 6, the Qt application would run correctly. But that means that the overriding you're asking for is unlikely to exist *today*. So if we're talking about the future, why is using an environment variable to suppress the Qt's override not sufficient? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development