[PATCH] Get rid of QPainter warnings

[Sebastian Sauer]

Thiago Macieira wrote:

> Sebastian Sauer wrote:
>>* the reason for the early adoption of 4.4. y, it may sound PR-like to
>> point to all the issues that got addressed to get things like painting
>> faster, to get widgets-on-canvas working, to address the SVG-issues,
>> etc. while someone who does not profit from this improvments just did
>> note that e.g. at least 2 new crashes got introduced to koffice-libs
>> (and worked around already). Well, the point here is that some
>> sub-projects of KDE are needing 4.4 asap while others would like to
>> avoid it till proven to be at least as stable as the prev 4.3 release
>> was. Really not an easy thing but imho that's something TT is totaly
>> unrelated here plus it's also total logical to stat that "I'm not
>> wasting anymore time when fundamental things are broken in Qt" since
>> there are other more important things a project may need to work on. No
>> idea how others see it but my personal feeling is, that this implicit
>> asks for a discusion about future release-policies how to handle KDE
>> vs. Qt-releases. I mean to just change the underlying base such late in
>> a KDE release-circle is really not a good thing and just asks for
>> frustration through I do understand that there was just no better
>> alternate for 4.1 for some parts of KDE :-/
> 
> The quality of the Qt release is deeply tied to the rate of adoption of
> the pre-release technologies. If KDE had waited for the final release,
> the end result would be the same level of stability and regressions. That
> happens because we fix the issues in the pre-release period as they are
> reported mostly from the KDE community.
> 
> If KDE decided to wait for the 4.x.1 or 4.x.2 release, KDE would find
> Trolltech developers less responsive to bug reports because they have
> already started working on new features.
> 
> Of course, having no regressions is our objective for each and every
> release. But, realistically speaking, we can't catch all cases. There
> will be regressions.

y, absolute logical. But on the other hand there is a desire to base own work 
on something stable. Probably a wild guess (based on my limited contacts with 
other devels), but I wouldn't wonder if much more then half of our developers 
are developing for that reason against the 4.0.x-branch rather then in trunk 
since not everybody is motivated to spend time to dig at the underlying tech 
rather then to improve his/her own work.
Anyway, I guess that's all still a temp issue like quit some ppl didn't "svn 
up" kdelibs any longer before 4.0 was published to prevent to trade known 
problems against new ones. So, that issue should hopefully go away once the 
big incompatible steps between stable-branch and trunk at code own work 
depends on arn't there any longer.