This was meant for the mailing list too I guess. Forwarding without reply first.
-------- Original Message -------- Subject: Re: [Opengov] Qt4 releases in a Qt5 world? Date: Sun, 22 May 2011 13:47:38 -0500 From: Coda Highland <chighl...@gmail.com> To: Stephen Kelly <steve...@gmail.com> Stephen Kelly wrote: > As far as I know, that's what the plan/goal is at the moment. Removing > deprecated stuff, merging overloaded methods into fewer methods with > optional arguments, turning pseudo virtual slots into proper virtuals etc. Well, just to bring up a simple example, QGraphicsScene::itemAt(QPoint) and friends are deprecated as recently as Qt 4.6 and I'm sure people still use it even in 4.7 because the alternative isn't obvious. Will this deprecated version be preserved in Qt5? Will the API be preserved but the behavior change? And where does the line get drawn? Qt 4.4 introduced a TON of new function aliases to do API cleanup but any code written to be compatible with 4.3 or earlier will of course use the older names -- is this proportion of code small enough to fit in this 5% of code that will need updated? These problems could be addressed with a qt4to5 tool could be provided to handle most of the changes here, but that's a task in its own right that will need to be designed, developed, and maintained. I think this is a better solution, though, than even trying to make a claim to some level of source compatibility. "Just a recompile" shouldn't be considered a requirement or even an ideal -- it should take lower priority than "do it right" in all cases. "Just qt4to5 and a recompile" on the other hand would be acceptable in my book, and since the differences between 4 and 5 are a lot less invasive than the differences between 3 and 4 this would have a much higher success rate than last time. > There's also a goal to get stuff into Qt5 through opengov such as better > localization, possibly replacing what's there or augmenting it in some > (maybe source incompatible) way. I can see plenty of areas that could > happen, so I'm not sure how the two goals intersect. We'll just have to wait > and see what happens. > > My point is that I'd much prefer opengov-driven features to go into Qt4. > With 4.8 feature frozen, Qt4 is feature frozen in general too. KDE won't > depend on Qt5 until at least 2-3 years from now. That's a long time to get > no new features. When Qt 5.0 is out there will come a point when there won't > be any bugfix releases for 4.8 either. The opengov community can't make > releases even if it wants to afaict. I'm pretty sure given the new requirements of Qt5 that Qt4's going to fork -- even if it's forking under community control instead of under the opengov umbrella -- in order to maintain it for all of the scenarios Qt5 isn't going to offer first-party support for. To be honest I'm really worried about KDE. KDE 4 has been under development for HOW long now? It certainly hasn't reached parity with KDE 3.5 in terms of stability and completeness. Sure, it has a bunch of shiny new features, but even now I'm still hearing complaints from users about bugs and missing non-shiny features. The Qt5 switch is a huge question mark in KDE's future, in my opinion, although that's neither here nor there and thinking about KDE shouldn't have ANY effect on the future of Qt -- the future of Qt is very clearly NOT KDE, especially since KDE even after all this time still doesn't run on anywhere close to the range of targets that Qt runs on. So this is really just an aside. > I wasn't around for the 3-4 transition, so maybe that was a similar > situation. I don't know. I WAS around -- I picked up Qt at 4.0.0 beta 2 and jumped immediately into a community support role in #qt as I started grokking the way things worked. I remember the problems other people were having. It's a very different scenario this time around; Qt 4 was more than just "fix the API" -- it was a massive restructuring of the entire library, while Qt 5 more or less COULD have been Qt 4.9 if we didn't want to fix the API and change some defaults in the process. One big difference is that Qt 3.3 had been feature-stable for a LONG time -- Qt's use outside of X11 was pretty rare (it happened but not nearly as often) so the feature development mostly went into KDE instead of Qt itself. Qt4 is still picking up features even now that discussion on 5 is underway. /s/ Adam _______________________________________________ Opengov mailing list Opengov@qt-labs.org http://lists.qt-labs.org/listinfo/opengov
