“The Qt development toolkit is undergoing a major overhaul. The developers behind the project announced the availability of the Qt 5 alpha release this week. It’s a key milestone on the path to the official launch of Qt 5, expected to occur later this year.” The kind of stuff to read Ars for.
fix the link. “href” attribute name, not “hef”.
Every time that i look how QT is maturing, the Nokia’s decision to jump on the WP7/Silverlight bandwagon becomes increasingly puzzling.
I have that feeling every time I look up pictures of the white N9 with MeeGo and I get tingles down my pants.
Use an N9 , then use a Lumia. Night and day. The N9 becomes painfully slow.
Under WinRT Qt will be a first-class citizen however, and Qt Quick and friends will suit the environment perfectly. It is pretty clear that WinRT will be the way forward on phones as well.
It is really misunderstanding the situation to think that Nokia jumped onto the WP7 bandwagon, they always jumped onto the Windows 8 everywhere bandwagon. Elop had the inside information on where this was going from the get-go.
Edited 2012-04-09 14:32 UTC
Finally someone gets it.
I wonder how badly the KDE project will be hit once Qt starts to mandate the use of OpenGL.
I mean, they will have to deal with either buggy Linux GPU drivers or ridiculously slow software OpenGL renderers, neither of which sound like a very attractive option.
Maybe, being KDE, they will try to provide users with a honest choice between both, in a dialog that shows up on first run : “We’re very sorry, but it seems that you didn’t get lucky as far as Linux GPU support is concerned. So, would you prefer your desktop unstable or sluggish ?”.
I guess I’ll have to learn wxWidgets on my side. Too bad, Qt4 was a nice toolkit…
Edited 2012-04-09 14:26 UTC
A slow GPU is still far faster than is needed to render typical application widgets. I feel some sympathy for the wxWidgets developers but when Qt went LGPL it rang the death knell for wx.
I’m not talking about slow GPUs but CPUs emulating GPUs, which is much worse than even the crappiest Intel GMA chip out there.
This is what awaits the numerous people whose GPU does not have proper support on Linux. Unless they are ready to endure the driver crashes.
Edited 2012-04-09 14:40 UTC
Software rastrerization can be fast. Microsoft does it in Windows 8 for Aero using WARP.
Counter accepted, though I’ll believe it myself when I see it.
Also, it’s not as if Microsoft *needed* a software rasterizer in Windows : they have the luck to be able to pressure GPU manufacturers into writing decent drivers. Perhaps that’s a way to address the issue of missing features in old chipsets, like Apple does since OSX Leopard, though.
Edited 2012-04-09 18:32 UTC
Several large QT customers use it on applications that hardly requires OpenGL, so if GL becomes mandatory, it will be for QT Quick only, i think. The old QWidget will be there forever for us.
But, putting a little though about this issue, KDE already requires OpenGL to be usable, even if they don’t admit it yet. When you disable OGL compositing, Plasma became so badly broken that you simple can’t consider it a serious option.
I don’t see anything broken in plasma with composition disabled. I always run without composition because it slows down other apps that need/can use opengl, like Krita.
But no, never seen anything that looked broken.
Yeah, every Linux user wants a toolkit that avoids completely using modern hardware-accelerated functionality. We all should aim for mediocrity.
There is a world between avoiding something and forcing its use.
Take cairo : it can use hardware acceleration when available, but does not ask you to emulate a GPU in software (which is pretty much what an OpenGL software renderer does, applying GPU-optimized rendering techniques to hardware that has a fully different set of capabilities) when no reliable driver is around.
This is how things should work when one cannot assert the presence of a decent GPU driver, as is the case on any minority OS due to the broken way GPUs are designed today.
Edited 2012-04-09 16:25 UTC
It works well for Gnome Shell.
That must be why for about a year it wouldn’t start up at all on my computer, simply redirecting me to a software-rendered fallback mode. Then open-source drivers finally got around supporting my hardware sufficiently well for Gnome Shell to work.
I do not blame driver manufacturers, don’t get me wrong, reverse-engineering proprietary drivers (that won’t even work on my machine) must be an awful lot of work. I do, however, blame Gnome Shell for relying on stuff that is only there late in the life cycle of a piece of hardware.
If you have the strong arm of Microsoft or the limited hardware range of Apple, you can work out the quirks of modern GPUs. But desktop linux does not have this luxury. Even Microsoft had some serious trouble when they updated their GPU driver model in the Vista days.
Edited 2012-04-09 16:44 UTC
Is that why the shell freezes, and then disappears, at least once every two hours?
This is a academic question since Qt does not nor will it in the forseeable future do that.
Since you are posting this as a comment to the Qt5 alpha announcement, I guess you might have misintereted the part of QtQuick2 now using an OpenGL/ES bases screen graph.
QtQuick2 is new in Qt5 and can therefore have update requirements, however everything that is in Qt4, e.g. normal widget based GUI, still has its present requirements.
The X11 platform plugin, for example, implements those parts via XCB, i.e. standard X11 capabilities.
But as far as I know, the Qt teams have pretty much stated that they are not interested in developing the QWidget part of Qt any further.
So for KDE, it will either be switch to QtQuick, or stick with a portion of Qt that is deprecated without saying it.
There are two things to that:
1) If Nokia doesn’t see any need to put resources into adding new things to the widgets library of Qt does not keep others from doing so. This is already happing with support for certain platforms (e.g. WinCE), so it is IMHO likely to expand to other areas.
2) Not adding new things doesn’t equal deprecating. The widgets library as it is continues to be useful for standard desktop applications as all features needed for those are already there.
KDE, and any other vendor using Qt, will use whatever is most appropriate for a given context.
Some products, e.g. KDE’s workspace shell, are already using a non-widget approach and will most likely switch to QtQuick.
Other products, e.g. Qt Creator, will surely continue to use a widget based UI.
And some products will use a QtQuick based UI in their mobile version while continuing to use a widget based one for the desktop version.
I personally expect most current Qt software producers to stick with a widget based approach and QtQUick mainly be used by companies starting product development for non-desktop applications
The GTK+ side of Linux GUIs has its trouble, but it’s doing something massively right: it’s fixing the development toolchain with the Vala and Genie languages, and that reverses the advantage that Qt enjoyed with C++ and MOC. Qt is good, but I wonder if it can change enough to continue being great.
The elementaryOS project is showing what can be done with Vala and Genie, and going to Javascript doesn’t seem to me like something that will yield the best results in the long run. Simplicity breeds simplicity.
Just like and obervation, I’ve seen how all markup GUI languajes had failed, Adobe AIR, Java FX, WPF, all those markup languages never really take off.
So, Will QML be the exception to the rule?
QT has had problems with toolkit orthogonality. By adding QML and a large javascript engine they’ve added yet *another way* to do things. At some point they need to reduce, refactor and simplify, not keep on tossing in more and more “fad” features. Didn’t MS recently annouce that c++ was “cool” again?
All those advantages were in the other scripting languajes also, and in some point even better, so I don’t see how QML is special in that area.
Wtf? Silverlight powers over 80k apps, WPF was a smashing success in LOB and XAML continues to be at the heart of Windows 8
QML is quite simply an amazing thing for Linux and the kind of forward progress their development story needs.
WPF could never had the success WinForms had and Silverlight is being slowly replaced for HTML5 inside MS.
That is why Visual Studio is now fully WPF.
Silverlight is, and has always been more than the browser plugin. So while HTML5 may be making inroads in the browser arena (By default, because HTML5 is still frustrating to use), Silverlight and WPF esque technologies still reign supreme in the LOB space.
However, the Silverlight XAML stack in Windows Phone has over 80,000 applications. With hundreds being added daily. So I don’t get how it can be regarded as a failure?
Then of course, the fact that XAML is now part of the core Windows Division and is instrumental in Windows 8 App dev also must mean XAML is a failure right?
Also, I think it’s illogical to suggest that XAML, or any other markup UI language is the core reason for any supposed failure. How exactly do you come to that conclusion?
To me, declarative languages seem to be the future of describing user interface. In fact, your own position is contradictory in that HTML5 uses a declarative markup language to describe its User Interface (At least for layout, with CSS3 for styling).
Qt5 is a major, major step in the right direction. What they’ve done is impressive, and it is technology I’m genuinely excited about.
So this means KDE 4 will be ditched and started from scratch to become KDE 5 in a few years, after driving their user base crazy?
end-rant
Not on the KDE project, but what leads you to believe that KDE must have the same major version number as the Qt toolkit on which it’s based?
While there is no official policy on this, they are the same. Here is why:
1) Because of there policy of maintaining binary compatibility for major numbers and because switching QT major version means broking that compatibility, they will have to increment the revision.
2) They can increment the major revision without switching QT version, but they will not do this unless they will be forced (by new development ideas)
Now lets also look at KDE history:
KDE1 – based on QT1
KDE2 – based on QT2 – major changes, unstable
KDE3 – based on QT3 – *minor changes, stable
KDE4 – based on QT4 – major changes, unstable
So i suspect that:
KDE5 – based on QT5 – *minor changes, stable
* Minor changes does not mean just some small new functionality, but the fact that the major components and architecture remain the same.
Ah, thanks. Guess I could have looked that up myself, couldn’t I? 🙂
But given your projection for 5, the Op’s “start from scratch” comment was a bit of hyperbolic trolling, I suppose. Which is good – I’m fond of Qt in general, and would like to see KDE get a fair shot in the tablet arena.
I’m sorry to read they’re phasing out C++ in favour of JavaScript. I don’t have anything against JS, but one of the main reasons I use Qt is because of how easy it is to lift my existing C++ code into Qt projects.
I’m sure JavaScript is great for small app developers, but I wouldn’t want to implement large projects in it.
Then you will be happy to read that you’ve misinterpreted the announcement’s text
Qt is still written in C++ and C++ is the main application development language.
Additional to that support for JavaScript in the context of QML base UI has been improved to a new level.
So if you are using QML for the UI of your application (which will still mainly be written in C++) you have now more and better integration between JavaScript and C++.
If you are not using QML nor QtScript for in-application scripting, then you don’t have to care about JavaScript at all.