On Fri, Dec 08, 2006 at 11:36:10AM +0100, Georg Baum wrote: > Am Donnerstag, 7. Dezember 2006 18:09 schrieb Andre Poenitz: > > > I am able to change my opinion when reality proves me wrong. > > Sure, only idiots never change their opinion. I was surprised because > to me the current status does not look much different from that of 6 > weeks ago. And to avoid misunderstanding: This does not include the > many bugs that have been fixed, but rather the cost of the abstraction > from qt4 in the core.
Some things need a while to settle down. And in fact I are right now so far off Qt in my daily work that 'Just use Qt!' is not necessarily the first thought when I read mail. [I am doing Windows installers right now. Far from funny to say the least, and a complete waste of time as far as I am concerned. One learns thing one never wanted to know of. Four weeks to get the graphical equivalent of 'rpm -i *.rpm' - without dependency tracking of course... And as a side note: I ended up using 'Windows Installer XML', not NSIS. This seems to get the most predictable results. Of course 'most predictable' does not mean 'predictable' at all...] Back to LyX/Qt. I had a sort of mental blockade earlier when I associated 'using the same library in frontend and backend' with 'blurring the line between frontend and backend'. Just because we use something in the frontend can't hardly outlaw its use in the backend if it is suited there as well. > > > Coincidentally I am seriously thinking to use QFile::encodeName > > > for the implementation of FileName::toFilesystemEncoding, because > > > it does exactly > > > what is needed. > > > > The whole file name business is pretty much reinventing the wheel, > > and so is the session stuff and preference management. Same goes > > for external processes when I think about it, but that does not seem > > to suck much resources nowadays... > > 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. > 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. > 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. > [...] > 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). I'd go even so far to consider 'support Qt' as 'a library on par with boost or libz'. I.e. even non-Qt frontends would not be required to replace it. Andre'
