Why preventing Qt4.5 to work fine with KDE4.2 is bad !

Reading Sebas’s blog (which unfortunately doesn’t offer way to comments, which makes the only way to comment, a blog post…), sounds like KDE4.2.0 is not compatible with Qt4.5, which is hardly a surprise, but what is more annoying is that it sounds like the whole KDE4.2.x serie is going to stay incompatible with Qt4.5 (I might be wrong on that point, but Sebas mentioned KDE4.2, so it’s unclear whether it is 4.2.0 or 4.2.x, in case I took the wrong assumptions, don’t hesitate to comment on my mistake and ignore what’s bellow).

The main thing is that all applications other than plasma or KDE4.2 might need to use 4.5, because they want to use a new feature, or an important bugs was fixed in 4.5. This is especially true in KOffice where one of the core component of an Office suite is developed inside Qt: the text engine. But this might be true for other project. Blocking the upgrade of Qt for the next six monthes seems very wrong to me. I hope plasma developers will reconsider their position, and provide a way for plasma 4.2 to work nicely with Qt4.5, so that progress in other projects isn’t disturbed by this.

This entry was posted in Krita, Open Source and tagged , , , . Bookmark the permalink.

28 Responses to Why preventing Qt4.5 to work fine with KDE4.2 is bad !

  1. 1JZZN8Uahsz8EiVN7Lgj2awBt9w- says:

    Very well said! Qt is a *shared* library. KDE is just one part of the ecosystem of software that uses it. IMHO, KDE shouldn’t be pressuring the distros to hold back on ugrading Qt versions especially since such a huge amount of work and bugfixes have went into Qt 4.5.

  2. Jesper T. says:

    You’re absolutely right Cyrille! Let’s hope that something can be done in plasma to resolve this issue. If nothing else, like you said, using 4.5 by 4.2.1 would make sense to me.

  3. Ruurd says:

    Well, it seems to me that the plasma devs just put their feet in the dirt and tell us they will not support Qt4.5. I think they have overlooked the fact that it is well possible that other KDE subsystems or systems that rely on KDE as their underpinning might benefit from basing KDE on Qt4.5. If the Plasma team did not discuss this with other teams, I think that holding their position is untenable from the point of view that they bar progress in other parts of KDE. Other than that, the biggest problem seems to be version-specific code in plasmoids. So? Get the plasmoids in line or throw them out in order to be able to coexist with Qt4.5.

  4. jospoortvliet says:

    Good point. At FOSDEM I spoke with some distribution developers who were asking about Qt 4.5 and the improvements in there. They wondered if it would be smart to ship KDE 4.2.x on Qt 4.5, considering the amount of bugfixes and performance improvements in the new Qt… I know many fixes in KOffice depend on Qt 4.5, and I was glad it would be release soon, opening up the way for a KOffice release within a few months.So I said yes, thinking it would indeed be a good thing to deliver KDE 4.2 upon Qt 4.5. I understand the issues with Plasma but I sincerely hope they can be fixed somehow…

  5. Paul says:

    A further chime of agreement. It’s not as if the plasma developers are the first ones faced with the problem of needing to maintain code that works with slightly different library versions. It’s what ifdefs are for…If plasma is that worried about breaking compatability then it should provide a featureset that it can guarantee will remain the same.

  6. Todd says:

    I had the same thoughts. We probably won’t be seeing KDE 4.3 until July (or the very end of June), while QT 4.5 is already in RC and will be out in March. That is at least 4 months using the old version of Qt.

  7. Leo S says:

    Will be interesting to see how distros handle this. If plasma blocks the update to Qt4.5 packages, plasma is getting uninstalled on my machine. Recent Qt versions are more important to me (development wise) than plasma.

  8. Marcus D. Hanwell says:

    I think you raise a very valid point. I do not think it is reasonable to ask distros to stick with Qt 4.4 until KDE 4.3 is out and some other solution needs to be found. Qt is very much a shared library and many other apps cannot wait that long for the Qt upgrade. I hope a solution is found in KDE 4.2.x.

  9. pelzowski says:

    So who will fix workarounds for Qt4.4 bugs in Plasma? Because best (and IMO only) solution for this is to ASAP delete workarounds in plasma code for buggy qt4.5 and update the plasma code in 4.2 branch to qt 4.5.Then distros will by able to ship qt4.5 with fixed KDE4.2.x-designed_for_qt4.5So who will do it? 😉

  10. Kristoffer says:

    i agree. I fail to see the insurmountable problems as it seems this blogger or the kde team think it is, to get kde 4.2 working on qt 4.5. Indeed i have been running kde 4.2 on qt 4.5 a couple days now(though i haven’t bothered recompiling any kde components) and it is much more stable than the “stable” qt version ever was.

  11. Tomé says:

    You are missing a point, Qt 4.5 is still an release candidate, an what sebas explained is that KDE 4.2 ins’t fully tested with the final release of Qt. Maybe in 4.2.x after some testing and bugfixing could be released with Qt 4.5.

  12. sebas says:

    You cannot increase the requirements for KDE in a minor version release, that one should be clear.Sure, something can be done in Plasma about this, but *currently* the situation is that behaviour in Qt 4.5-rc is different from 4.4 and that we simply cannot guarantee that everything that works with Qt 4.4 (which we've tested quite extensively during the beta / rc cycle for KDE 4.2) also works with Qt 4.5.Right now, nobody has stepped up to provide a set of patches and the testing needed to make it a sensible combination. Also, we're unsure if this is an issue for people, so we raise the issue now, before things go horribly wrong.So you can go all wild and hand-waving and shout "oh noes, I want the latest stuff" but reality *right_now* is different.I'm also not saying we cannot do anything about it, sure we can. It is *not* planned right now, however. Making people aware that the 4.4 -> 4.5 step is not 100% transparant was one of my goals. If you don't like that, we'll have to do something about it. And it's not that we don't *want* to.The situation simply is that _currently_ it's not guaranteed to work.Isn't finding out about this the whole point of doing an RC, btw?I might be able to invest some time to help people make it more compatible, though. I have a pretty good idea where to work, but without that effort, it won't work well. And nobody has invested time in making sure it works yet.

  13. sebas says:

    Just to make it even more clear:Nobody says the plasma team doesn’t *want* to support Qt 4.5 in KDE 4.2. It’s just that current KDE 4.2 might have issues with Qt 4.5.

  14. KAMiKAZOW says:

    Porting KDE 4.2 to Qt 4.5 is a waste of time. KDE 4.3 will ship only 5 months after KDE 4.2 (not 6) and porting 4.2 means that there will be less new features and less bug fixing in 4.3.KOffice is still in beta anyway and it won’t just be in release shape because of Qt 4.5. So instead of bitching at the Plasma developers, just do your work in KOffice — the first alpha was release 1.5 years ago and there’s still no sign of a final release.

  15. Ruurd says:

    You know what? From reading this whole thread I get the uneasy feeling that the plasma team is going in a direction of degrading quality. How is it possible that Plasma heavily relies on version-specific behavior in the first place?So what I cannot change requirements in a minor version? Then make it a major one. I support the idea of basing KDE4.2 on Qt4.5 if it is beneficial for a number of systems that rely on KDE. If there are plasmoids that depend too heavily on version specific behavior and have workarounds, then move them out of the way. If it is functionality that relies on version specific behavior, then delay it until the underlying Qt has been fixed. If that does not go fast enough, complain more to the Qt people.

  16. Pan, Shi Zhu says:

    Sorry, but I cannot see the point. KDE 4.2 is a release, and by that time Qt 4.5 is not released so it is natural that KDE 4.2 uses Qt 4.4. For KDE 4.2.x minor versions it should only contain bugfixes so it keep with Qt 4.4. Qt 4.5 will be supported in KDE 4.3, and if developers want KDE 4.3 it already is there, the KDE svn trunk is KDE 4.3 now! KDE 4.2 is released and IMO the main man-power should be put into KDE 4.3.

  17. David says:

    Pan Shi Zhu : +1KDE 4.2 is out, and at the time of release, the latest Qt was (and still is) 4.4.KDE 4.2.X are bug fix releases which in all logic means no feature changes, and definatly no movement in dependencies. Trying to do otherwise will result in the same garbage we had last year, where distros shipped KDE 4.0_with_patches_from_truc_since_4.0_wasn’t_really_meant_for this, and all the shit going back upstream.Please Please Please let the Plasma team do it’s job and accept that 4.2 isn’t guaranteed future proof against Qt4.5 (how could it be since 4.5 isn’t out yet). 4.3 will be out in June/July with the latest Qt goodness.

  18. jospoortvliet says:

    To be fair to the Plasma developers, Qt is supposed to be backwards compatible – and cleary 4.4/4.5 failed at this.Any KDE app which uses normal, available Qt features should work fine on any version equal or later than the one it was developed on. So we can’t blame the plasmadevelopers for having to work around bugs in Qt…Nonetheless, it would be great if it were possible to use KDE 4.2 with Qt 4.5, as that version introduces bugfixes and performance improvements.

  19. Cyrille Berger says:

    @David, Shi ZhuYou are missing the point, I don’t care that plasma use Qt4.5 or Qt4.4, but by preventing plasma to use Qt4.5, it’s blocking the use of 4.5 by other projects. When KOffice 2.0 is released it’s going to be dependent on 4.5, because 4.5 includes important bug/crash fixes. And whatever people like KAMiKAZOW think it’s going to happen before 4.3. And KOffice 2.0 isn’t the only project outside KDE4.2 that use Qt as a library, there are countless open source project that depend on it and might want to use Qt4.5 before KDE4.3 is out, which is going to become a problem if distributions can’t ship Qt4.5.@jos, yes you are right, the issue is a difference of behavior from Qt4.4 to Qt4.5, this is something that happen on a regular basis, especially for newly introduced features. Yet, sebas mention hacks and workarounds, and if there is something to know about hacks and workarounds, they are always going to backfire on you.

  20. KAMiKAZOW says:

    OK, then I’m positively surprised that you plan to release KOffice 2.0 before KDE 4.3. But when KOffice 2.0 relies on Qt 4.5 anyway, why don’t you just postpone the KOffice release a bit to be simultaneously with KDE 4.3? It’s in pre-release state for 1.5 years — a few weeks later won’t make any difference.

  21. Jake Sallee says:

    Yet another reason why KOffice, Plasma, KDE, and major KDE projects should align their release schedules.It’s not that hard people. Schedule. Communicate.“Assuming” that the “plasma devs” are going to have everything worked out of plasma so everyone can write programs with Qt4.5 (release candidate) is not a good practice.“If the Plasma team did not discuss this with other teams, I think that holding their position is untenable from the point of view that they bar progress in other parts of KDE.”In that same thought, why couldn’t the “other teams” communicate with the plasma devs?Sorry, but the plasma devs are held more responsible for things not working than most other KDE teams. I don’t necessarily think that the Plasma team should be held responsible for fixing plasma to work with Qt4.5 which has been in beta and RC form for quite some time.

  22. Kristoffer says:

    Statement: There is no problem. Kde 4.2 can be used with qt 4.5 with very little effort on the part of the devs, this is because the QT devs have been testing KDE 4.2 with qt 4.5 all along during their development schedule.see: http://labs.trolltech.com/blogs/2009/02/10/why-kde-42-should-use-qt-45/I am running kde 4.2 on qt 4.5, not even with qt-copy, and have /less/ bugs than I had with kde 4.2 on qt 4.4.3. According to the above this is also the case for others. So if distribution ship kde 4.2 with qt 4.5 they will see /less/ bugs, _even_ in current state. If kde devs/qt devs spend one day or two days actively fixing bugs in kde 4.2 pertaining to qt 4.5 they will get a very stable GUI!(relevant or not relevant: i deleted .kde4 and started afresh when i updated the qt version, don’t know if it makes a difference)

  23. fgunni says:

    Just the view from a “dumb” user and KDE-Fan:I hope there will be Qt 4.5 for KDE 4.2.x as i hope for more stability.Currently, although i love KDE, there are so many bugs, crashes and more, that Qt 4.5 can hardly make it worse.

  24. Pinheiro says:

    Just to say that Qt4.5 intruduced a problem that did not had in 4.4 it dosent do grouped alpha in svg, this is a important feature in kde and specialy in plasma….Yes we can overcome this issue by redoing the themes, and probaly we will have to do so.But the svg theme was ok and is rendered correctly in most svg renderes Qt4.4 actualy did a beter job at this specific joob.And if you want a correctly rendered plasma themes today you should not use Qt 4.5.Still thank you Qt the windows scale much faster now :) and im sure we can fix this bugs.

  25. Pan, Shi Zhu says:

    I think the situation is quite clear: Plasma team is in short of human resources and had to focus on KDE 4.3. If distributions want to ship KDE 4.2 with Qt 4.5 they should fix the problems in KDE 4.2 where incompatible with Qt 4.5.No one is baring Qt 4.5, but Plasma team should focus on KDE4.3 so those who want Qt 4.5 with KDE4.2 should co-operate and try to fix the problems, which shouldn’t be very hard and is encouraged.

  26. Kevin Kofler says:

    Unless something really bad happens, Fedora 11 <>will<> ship with Qt 4.5. We will import it into Rawhide soon, so we will be delivering the testing some folks (e.g. Aaron) are asking for. Hopefully we can get the kinks sorted out. Most likely it’ll also hit Fedora 10 and possibly 9 updates before KDE 4.3, maybe even before the Fedora 11 release.And to us, it matters very much when KOffice 2 releases, because we want to ship Fedora 11 with KOffice 2. In fact, Rawhide already has the prereleases. (We even wanted to ship KOffice 2 in Fedora 10, but had to revert to 1.4.) So I hope the KOffice team won’t get pressured into delaying their release.FWIW, I also wouldn’t complain if a later 4.2.x release started requiring Qt 4.5, as long as it fixes the issues with 4.5. We can just push out 4.5 as an update to earlier Fedora releases.

  27. Cyrille Berger says:

    @KAMiKAZOW and KevinWhat decide KOffice 2.0 schedule is 2.0 stability.Delaying 2.0 to wait for plasma 4.3 would be silly, since plasma isn’t a dependency of KOffice, nothing prevent you to use KOffice without plasma, while the main userbase of KOffice is KDE users, and it will stay that way for a while, we already have people who test KOffice and use gnome, windows or Mac OSX, those people don’t care about plasma and wether plasma works with 4.5, and among KDE users, there are some people who care more about applications than a few glitches in plasma.An other point to consider is that delaying KOffice to wait for KDE4.3 won’t necesseraly make it better, since when it reaches a reasonnable stable state (the one we would have used to release 2.0), we would probably want to start working on the 2.1 branch, while the 2.0 branch would be left to wait for at least three monthes.And we all hope, in the KOffice community that the release will have a significant impact on our moral (3 years of development without stable release, and more than a year of stabilization has a negative impact on that) and on the visibility of the project, which is also why we want the release sooner than latter.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>