Am 05.01.2012 um 02:40 schrieb André Pönitz: > On Wed, Jan 04, 2012 at 05:19:02PM -0500, Steve Litt wrote: >> On Tuesday, January 03, 2012 03:36:16 PM Stephan Witt wrote: >>> Am 03.01.2012 um 17:15 schrieb Olivier Ripoll: >> >>>> Hi, >>>> >>>> Check my 2 messages in the "LyX 2.0.2 Released" thread, one dated >>>> december 5th (user mailing lists, perhaps devel too) and the >>>> other one dated december 16th (devel ML), which contains more >>>> details: >>>> >>>> http://www.mail-archive.com/[email protected]/msg90218.html >>>> http://www.mail-archive.com/[email protected]/msg172462.htm >>>> l >>> >>> Hi, >>> >>> I'm almost sure it depends on Qt-Version. >>> >>> With LyX on Mac with Qt4 we have two fundamental problems: >> >> At the risk of sounding like a broken record, if Qt continues to >> produce these types of problems, isn't there different library or >> combination of libraries the developers can use? > > At the risk of sounding like a broken record: Some of the issues in the > past have been caused by wrong usage within LyX (like repaint() instead > of update()), and some by insisting to use Qt versions that have been > released before the other components in the system, like newer versions > of MacOSX. I just run svn up and README says "The Qt4 library, at least > version 4.2.2. For all features newer versions (e.g. Qt 4.6) are > recommended." _Please_? That was state of the art in _2006_? > > That is not to say that Qt is flawless, Enrico(?)'s execvp/exeve > issue for instance. But the thing _is_ open source, too, so if it's > a pain point, fix it.
I second that. At the time of the move to Qt-exclusive it was debatable. Now this isn't possible anymore. And Qt is an excellent toolkit. > >> Back when I wrote my "why oh why did you dump xforms" rant, it seemed >> like maybe the compile problems were just growing pains from Qt going >> from version 3 to version 4. But now it's years later, and we're still >> hearing (I paraphrase) "the quality of your LyX program depends on >> your Qt version." >> >> I know, you've told me before, Qt does a lot of busywork and makes >> programming LyX much simpler. It handles all the localization, etc. >> Programming LyX without Qt would be a horrendeous chore. >> >> But is Qt really doing you a favor when certain Qt versions make your >> program perform badly? > > *gosh* > > The main performance problems I have seen so far are due to an abuse of > the toolkit, not caused _by_ the toolkit (except for the remote raster > painter problem perhaps). Just start at RowPainter::paintChars() and > walk down through all the mess _before_ it actually hits Qt's drawText() > It is slow? You bet. Note, I've said: "we have (aka LyX code has) a problem". This isn't easy to change - and we all do it in our spare time. Everything around is a moving target - the OS and the Qt library. And it isn't possible for every move to avoid drawbacks for the late comer. For the painting problems: it started with broken ligature drawing and the (re)action of LyX coders was a hack (split the text drawing at the letter 'f'). As support for kerning for on-screen drawing was added (Qt 4.7 AFAIK) the consequence was to split at every character. Obviously a rework of the painter/cursor movement code is a much better action... but someone (who gets no money for this) has to do the job. I had a look into this and decided I cannot afford that. I have a real live too. All in all André is right: it's not the toolkit Qt, it's the use of it. Stephan
