On Fri, Dec 08, 2006 at 06:28:45PM +0100, Andre Poenitz wrote: > On Fri, Dec 08, 2006 at 11:36:10AM +0100, Georg Baum wrote: [...] > > Now you ignore the fact that all this stuff (except sessions) exists > > already from the multiple-frontend times, so I don't see much > > reinventing the wheel here. > > Well, there was work on sessions. Seems to work now, but it took a while > to get right and it sucked not only resources from the person actually > working on it. I doubt that a QSetting based solution ever would have > led to a stage where _I_ can't even start up LyX because of a courrupted > settings file.
C'mon, the problem was promptly solved, and I don't know if it would have been the same with a QSetting based solution, where you should hope that the bug is fixed by others. > > I don't consider introducing the FileName > > class reinventing the wheel either, since it only uses existing code. > > And this code is made up of a third party library plus quite a bit of > our own glue code which needs to be maintained and also requires > knowledge about specific platforms. I think that you cannot avoid to know the specifics of a platform if you want to support it. > > The difficult part was the correct conversion from string, considering > > relative and absolute names. > > And that we could get by using a third party library without glue code > of our own. And note: It would have worked correctly immediately on the > Mac, too. Instead we are guessing at how different systems encode their > filenames ourselves. See above. > > [...] > > Now to the important stuff: The attached patch makes non-ascii > > filenames work for me in a latin1 locale. You can ignore the client > > part, that has nothing to do with filenames, but it shows thet some > > work is needed there as well. This patch uses qt to implement > > FileName::toFilesystemEncoding() and the new functions > > from_local8bit() and to_local8bit(). I don't want to copy the code > > from qt, since it is really messy, and I don't see any point in not > > using what qt provides. The patch is not very clean (see > > qstring_to_ucs4), I would like to use something similar. > > > > What do others think? Please not that this patch does only introduce > > Qt in the implementation of the support library, so if we should get > > more frontends in the future it would be easy to separate this out > > (but of course the new frontend would need to provide similar > > functionality). Frankly, I don't like the new filenames organization, as now on cygwin I have to use wrappers for latex and pdflatex, too. But there's no problem: I can jump through whatever hoops I am presented with. This is not your fault, it's mine for stubbornly not accepting to follow the mainstream. -- Enrico
