Home > Krita, Open Source > Why preventing Qt4.5 to work fine with KDE4.2 is bad !

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.

  1. 1JZZN8Uahsz8EiVN7Lgj2awBt9w-
    9 February, 2009 at 14:55

    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.
    9 February, 2009 at 15:08

    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
    9 February, 2009 at 15:09

    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. vivo
    9 February, 2009 at 15:13


  5. jospoortvliet
    9 February, 2009 at 15:36

    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…

  6. Paul
    9 February, 2009 at 15:41

    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.

  7. Todd
    9 February, 2009 at 15:46

    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.

  8. Leo S
    9 February, 2009 at 15:57

    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.

  9. Marcus D. Hanwell
    9 February, 2009 at 16:00

    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.

  10. pelzowski
    9 February, 2009 at 16:29

    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? 😉

  11. Kristoffer
    9 February, 2009 at 16:35

    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.

  12. Tomé
    9 February, 2009 at 17:20

    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.

  13. sebas
    9 February, 2009 at 17:25

    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.

  14. sebas
    9 February, 2009 at 17:27

    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.

    9 February, 2009 at 17:32

    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.

  16. Ruurd
    9 February, 2009 at 23:06

    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.

  17. Pan, Shi Zhu
    10 February, 2009 at 01:34

    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.

  18. David
    10 February, 2009 at 08:34

    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.

  19. jospoortvliet
    10 February, 2009 at 09:20

    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.

  20. Cyrille Berger
    10 February, 2009 at 10:54

    @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.

    10 February, 2009 at 11:53

    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.

  22. Jake Sallee
    10 February, 2009 at 16:45

    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.

  23. Kristoffer
    10 February, 2009 at 17:38

    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)

  24. fgunni
    10 February, 2009 at 21:07

    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.

  25. Pinheiro
    11 February, 2009 at 00:05

    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.

  26. Pan, Shi Zhu
    11 February, 2009 at 03:56

    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.

  27. Kevin Kofler
    12 February, 2009 at 02:54

    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.

  28. Cyrille Berger
    12 February, 2009 at 09:30

    @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.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: