Sebastian Kügler blogged yesterday about why distributions shouldn’t jump on upgrading to Qt 4.5 while shipping KDE 4.2. This caused quite a stir in the community as well as inside Qt Software. Sebas then replied to Cyrille’s blog explaining a bit more (if the link doesn’t work, scroll down; blogspot comment links don’t do anything for me).
Sebas is right: Plasma developers did not test KDE 4.2.0 with Qt 4.5. So there may be issues that they have not seen or corrected. That’s entirely true and no one can blame the Plasma developers. After all, resources are limited and prioritising the work was necessary. Therefore, distributions should be careful when upgrading Qt, because they may introduce problems. But, then again, isn’t that the job of distributions? To make sure their package set works without issues? And in case patches are needed, they can backport fixes from upcoming releases or introduce a temporary hack.
However, Sebas is right only up to a point. We at Qt Software have done testing of Plasma with Qt 4.5. In fact, we know it works better with 4.5 than with 4.4.3, though some of the qt-copy patches help somewhat. Has anyone noticed that the system tray finally works in 4.5? But, more importantly, other parts of KDE (other than Plasma) benefit greatly from Qt 4.5.
Just to give you an example: I still build my KDE trunk with Qt 4.4, then run with 4.5 on my main development workstation, but with the standard 4.4 (pristine, unpatched) in my laptop. After logging in to KDE, I usually get Kontact crashing within 5 minutes of using: when I click on a folder, it crashes with a dangling pointer dereferencing. Then I remember I have to restart it with QT_NO_SHARED_PAINTER=1. But this crash never happens on my workstation: standard 4.5, pristine, unpatched.
What’s more:
- We did lots of testing and fixing of KDE 4.2 for Qt 4.5, but not with Qt 4.4
- We did a lot of fixing and stabilisation in 4.5 itself and most of these changes did not make into 4.4
- Performance improvements in 4.5 are noticeable, especially in the painting code and itemviews
I can hear the arguments saying that those fixes should have bene done in the 4.4 line and that we should have prioritised that over the feature release. I know those arguments because the discussion happens in Qt Software too: it’s only natural to have it. But the same way that Plasma developers were faced with a finite amount of resources, so were we: we had to prioritise work. Qt 4.5 is the future and we needed to stabilise it, so we did focus most of work there. (We did not forget 4.4, you can find several fixes in the Qt 4.4.4 snapshots)
And I don’t have to say that we can’t fix further issues unless they are reported to us. If people don’t use 4.5, those issues will not be found (read: our QA people can’t find every single issue). With the 4.4 release, we had a very good feedback from the KDE community: KDE 4.1 started using 4.4 very early, I think even before the beta (Feb 2008). That means we had a lot to work with in order to stabilise Qt 4.4. By the time of the 4.4 release candidate, we had had two months of continuous feedback and stabilisation work done. And we have one more month left, more or less, by which time KDE 4.2.1 (with its own set of fixes) should be out.
And my personal, subjective experience comparing now (4.5 RC) to 10 months ago (4.4RC), things are a lot better and more stable.
Possibly related posts:
27 comments
I agree with you. We already know about problems and bugs(Qt 4.4 and KDE 4.2). This is the reason I want Kubuntu 9.04 to come with Qt 4.5 and not 4.4.
The main problem, more than trunk is 4.2, according to Sebas’ blog post: the hacks needed for Qt 4.4 were removed in trunk already. Did you test 4.5 with 4.2 branch, rather than trunk?
Yes, most tests were done before 4.2 was released and branched.
Is the situation going to improve thanks to the new 4.5 git development model? I mean, will the difference between the official Qt Software release of Qt and the KDE qt-copy version be lower?
To tell you the truth, I don’t know.
On one hand, yes, we should be able to have less changes once we start accepting patches more openly. However, it will also make it easier to backport future changes and keep them, without running into conflicts.
Only time will tell.
I am running 4.2svn with Qt4.5 without problems in Plasma front. And all apps are benefiting from -raster option
My personal, subjective experience comparing now (4.5 RC) to 10 months ago (4.4RC), things are a lot more fracked up on windows.
After several obvious problems on Windows, I can’t say that I trust it at all. It may be ready for Linux, but not in the least for windows.
For the beta, HTML table grid lines were not drawn correctly. That did get fixed for RC1.
The demo app did not work on my ATI computer, but works fine on NIVIDA.
I can’t compile QtKinetic’s snapshot of Qt. In fact, I never have been able to. (mingw32) So I was surprised people were talking about Keniticing Plasma…
I just feel that anything other than Linux at this point is a 2nd-rate Qt 4.5 implementation. I think you’ve put too much time into KDE/Linux testing and not into the other platforms. (How is KDE/w32?)
As for qt-copy, I frankly would be pissed too. Because even though you at Qt have taken on the testing, its simply not your call. The app maintainers will be hit with the feedback complaints. Unless Qt is also the maintainer you are subverting the proper development process. I do think that running it as a test for Qt was a good idea, but you crossed a line that should not have been crossed when you started fixing KDE for 4.5 instead of fixing for Qt4.4. Now you have a clusterfrack of deltas.
Sorry thiago but did you test the svg rendering capabilities, for some reason qt 4.5 dosent aply group opacity…. this is used on plasma right now…. any theme that aplyed group opacity to any svg group gets opacity = 1, it worked on 4.4.
Scorp1us: please make sure you have reported those issues. This is the first I’m hearing of grid lines problems and the demo app not working. Our machines in the office have mostly NVidia cards, but there’s no reason why ATI wouldn’t work.
As for Kinetic, it’s a Qt 4.6 feature. When it makes into 4.6, it will have the same level of quality as any other parts of Qt. Until then, please expect problems and please submit patches.
As for qt-copy, we did not make the decision. The decision came out of KDE.
Finally, please understand that we tested KDE 4.2 as part of our regression testing: run the application with Qt 4.5 and see if anything looks broken. If it does, we try to fix in Qt what went wrong. That’s why I said it works better in 4.5. In an ideal world, KDE would look exactly the same with 4.4 and 4.5, but it’s not an ideal world. In doing our tests, we discovered lots of KDE bugs, with either version of Qt. And when it came to fixing them, we fixed for the correct behaviour of Qt (fixing Qt 4.5 in the process to match that behaviour). Or, phrased differently: we did not add workarounds for Qt 4.4 bugs.
KDE on Windows and on Mac are viable alternatives, but the quality of the ports is limited. That comes as no surprise: you can count on the fingers of one hand how many KDE developers are working on Windows, whereas the number of Linux developers is much, much higher. In any case, we have tried it: please see Maurice’s post (blog to which you replied).
Dealing with different versions isn’t something new to Qt Software, nor to any serious developer. Althought I can somehow understand your arguments about manpower, still it is a bad idea to not fix bugs in the current stable line of 4.4.x but only in 4.5.0. Many of your paying customers are relying of Qt as (hopefully) stable platform for business scale applications, and forcing them to make the step from 4.4.x to 4.5.0 in hardly acceptable. Don’t get me wrong, sure most will at some point make transition from 4.4.x to 4.5.x, but not for the .0 version – as experience it will take a while to iron out bugs on all platforms. This leaves us quite a while in a situation where we have to decide between a no longer seriously bug fixed 4.4.x line, and a 4.5.x line which has not yet reached maturity.
@pinheiro : As i told you, the group opacity didn’t work on 4.4 at all, and in 4.4 the fill-opacity attribute wasn’t parse at all so that mean it was “working”. In 4.5 it parse the fill-opacity in gradients (which is 1 in some Plasma SVGs) and that explain the black border. But because it still broken with opacity groups, the bug is more visible now.
@alexis.menard but from an end/user point of view its worts now right? And thats the point, I gess of sebas post, the uzer experience.
I like the reasoning from Thiago, and its something I can follow.
My reasoning to counter sebas’ post is following a different line of thought and is based on two points;
1) Qt45 is still only a release candidate. Its expected that KDE release its 4.2.1 at about the same time as the final Qt4.5 comes out. This gives the plasma devs time to make their code work for both Qt versions.
2) Many KDE applications gain quite a lot from 4.5. From the top of my head; KMail and KWord crash regularly using 4.4.3 and those problems are fixed in 4.5. I think crashers trump plasma prettiness (user-experience) issues.
Thank you for clarifying the issue however I’m left wondering how an end user like me can work with KDE 4.2 and Qt 4.5. (I build both KDE and Qt from sources as I don’t use distro supplied packages). What are the exact actions I should perform to make everything silky smooth?
The Qt Team are scaring the developers !
We already scared with the Nokia aquisiotion, and we are MUCH more scared that the Windows Port is NOT a priority anymore.
We want WINDOWS LOVE ! Please ! We not interested in a Linux toolkit.
Acenes: that’s exactly the reason why we did not introduce so many bugfixes into 4.4. We did introduce some: the most pressing and most important ones. You can find many fixes in the task tracker that are assigned to Qt 4.4.4. We know fairly well that customers will wait a while longer before upgrading to 4.5.0 (read: more than the day after the release).
Qt 4.4 is stable and works very well for customers. Sure, there are bugs, but everything does. The problem is that, with every fix, there’s a chance of introducing another bug or even a regression. So we have to balance the need for the fix with the breakability-potential. And for the 4th patch-level release of a series, the bar is very high.
Like I said before, most of the fixes we did because of KDE were done in the context of the regression testing: making Qt 4.5 behave the same as 4.4. I said before: “In an ideal world, KDE would look exactly the same with 4.4 and 4.5, but it’s not an ideal world. In doing our tests, we discovered lots of KDE bugs”
Wilson: sorry, but what gave you that idea? I feel rather offended that I have to say that Windows is and remains a major platform, with equal footing as the others.
First of all, I marked this blog under the “KDE” category, not “Qt”, so don’t blame me for not addressing Windows. Second, no one said Windows is not a priority. Third, I did mention in a comment that we even tried KDE on Windows.
@Wilson: You’ve just presented typical windows user’s arrogance. “We want, we demand, we’re not interested in anything non-windows”. Wake up, it’s not windows-only world, hello. Make a commitment, send patches, do testing file bug report.
For what it’s worth as a developer using Qt 99% on Mac and the other 1% of the time on XP/Vista I find Qt works very well on both of these platforms. If anything the Trolls have been putting more and more effort into these platforms over the last year or two.
That said, I also tend to be in the category of only switching to a 4.x series once Qt hits 4.x.1. The 4.x.0 releases often have one major regression I can’t bear with.
I’m a bit confused about whether the bugs in KDE 4.2 running on Qt 4.5RC1 should be submitted to KDE team or to Qt team. For example, I’ve tried to installed Qt4.5rc1 today and first of all – got all my fonts broken, that turned out to be a problem with subpixel hinting – “vertical” hinting modes break everything on the screen. Then I’ve moved on and found out that akregator is unusable with Qt4.5 as it doesn’t remember width and position of it’s columns. So I’d like to report these things to help get them fixed, but to whom?
On the archlinux forums there are reports that KDE 4.2 works great with QT 4.5 EXCEPT for KDM, which does not work.
http://bbs.archlinux.org/viewtopic.php?id=64750
fascinating… I know there’ve been problems getting certain components of rc1 to build on gentoo.
@windows users
now you know how we feel when all you support is windows, and if users are lucky you support mac. I personally hope that linux remains the top priority platform for qt/kde. Am I saying we shouldn’t support windows/mac? no, just that we should keep foss platforms as our #1 priority.
Mozilla started out on Linux and now they barely support us, I’m impatiently awaiting the day that I can replace firefox with konqueror.
Its amazing how poor Firefox has become on Linux. And Konqueror… just… doesn’t support anything. Anyone know what’s going on with KHTML? I can’t find any progress… Soon, I’ll be able to do all my browsing in Arora (once I have Qt 4.5 == Flash support, yet another reason KDE 4.2 should use Qt 4.5) Or maybe just use QtWebKit (WebKitKDE) in Konqueror, if/when it’s sufficiently mature. We’ll see.
@caleb, kde 4.2 with qt4.5 under gentoo it’s so broken
kopete notify doesn’t work anymore, plasma has some kind of pixel lines, akregator has amplified a bug which had (column width isn’t saved… it’s an akregator bug, but with qt4.4 the width is reset only sometimes, with qt4.5 it’s always)… next week i’ll get a new laptop and i’ll surely put qt4.4 for now 
btw with the 4.5 there is a noticeable increase of speed
@morhekil unfortunatly it’s a more than a year old bug: https://bugs.kde.org/show_bug.cgi?id=152702
I only hope will see this fixed by kde 4.2.1, akregator in this state is really unusable
@mark : kopete works perfectly here, notifications. The pixel line pixel has been fixed in the final 4.5 (you just need to clear the plasma cache in .kde4/cache-*/kpc/plasma_). The agregator bug is unfortunatly not related to 4.5.
@alexis: which qt version do you run? i’m with 4.5.0-rc1 and kopete notifications doesn’t work
about the pixel line, perfect, thanks
yep, i know that the akregator bug is not a qt one, but with qt4.4 it happened only sometimes, with the new 4.5 it happens always. btw it seems that it has been fixed, so, hopefully, the next kde 4.2.1 won’t suffer this anymore
Do you have any hint on when the final 4.5 will be released? i know that it will be the next month, but it’s more for the beginning or the end of the month?
Comments on this entry are closed.