On Fri, Jun 15, 2007 at 11:39:23PM -0400, hzluo wrote: > >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?
What was from with the five lines or so I posted that uses QCoreApplication::arguments()? Andre'
