Thiago Macieira wrote: >> the lesser evil is imo assuming correct locale encoding when actually >> interpreting external input, being consistent within the qt realm when >> dealing with i/o functions, and having functions for 8-bit pass-through >> when dealing with external things which are just passed along >> (qprocessenvironment already has this; it should be possible to do the >> same for cmdline args by having laszlo's work integrate with qprocess as >> well). > > I agree on that too. Which is why I am telling João that the idea that > filesystem encoding != locale encoding is insane. It simply cannot be > implemented properly.
We're not discussing whether it's sane or not. I'm interested in enabling the user to act on "broken" files from within Qt applications. Qt is a general purpose toolkit, it should not unnecessarily limit what you can do, even if it makes you jump through hoops in some cases. Qt can see these broken file names and will point them out with a healthy dose of '?'. How do application developers explain to their users that the files they see they don't really? "Yeah, just ignore those, your filesystem is corrupted. There are plenty other files you can play with. Here, have a balloon!" As I see it, enabling command-line arguments to be treated as random 8-bit gibberish is a separate and specific problem. I don't think encode/decodeName is the right concept to use there, though we could very well have an encode/decodeCmdLineArg pair. It might suffer from the same shortcomings of current encode/decodeName in terms of portability, though. Cheers, João _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
