We've been relaxing the rules lately; support/ uses QtCore for a number of things and I think it would be much saner at this point to use QFileInfo, QProcess and QNetwork to replace our hand-made local code. If somebody steps up to encapsulate this Qt API in our API (forkedControllers, Socket and FileName) he will have at least my full support (and help) and probably not much resistance from others.
But it needs a _lot_ of change. All file open/create must be patched. As a result, the work needs the involvement of the whole lyx development community. It's kind of impossible thing for me. And I don't think it's worth to do so. Certainly, if this problem lies not only on Windows but also on other platforms, it may worth to have a though clean of the code. And I just tested that Qt converts the filenames between local encoding and UTF-32 correctly. So the evil is solely from M$'s disgusting stdc++ library. I really hate this -- even though Win32 API supports local encoding very well, M$'s clib breaks it completely...... I'm trying to hack the disgusting M$ stdc++ library to allow proper local 8-bit filename support. In that way we do not need to patch anything other than M$ library. And one programer is enough. If this problem affects only Windows, I believe it's good enough. Now the remaining problem is to test whether other platforms and compilers/stdc++ libararies have the same problem. I do not have access to such platforms so I can't do the test. Could anyone help to test it? Hangzai
