Nokia Announces Qt 5 Plans 129
aloniv writes "Since Nokia announced its switch to Windows Phone 7, people have been worried about the future of Qt. Well, it turns out Nokia is still going full steam ahead with Qt, having just announced their plans for Qt 5. Some major changes are afoot code- and functionality-wise, but the biggest change is that Qt 5 will be developed out in the open from day one (unlike Qt 4). There will be no distinction between a Nokia developer or third-party developer."
Dupe? (Score:1)
I could swear I read this on Monday.
Re: (Score:2, Insightful)
Re: (Score:2)
No kidding. I tried out Qt for the first time just before the MS deal was mentioned, and subsequently haven't bothered with it. If they're switching to a more open development model that will help to ensure it continues even if Nokia are savaged by MS, and if it's ported to more platforms, then that's enough reason to continue using it.
Re: (Score:2)
It's LGPL. It can be forked at any time.
translation.... (Score:5, Insightful)
Re:translation.... (Score:5, Funny)
"There will be no distinction between a Nokia developer or third-party developer."
Which will be a disapointment for any Nokia developers hoping to get paid.
Re: (Score:2)
Isn't that basically the philosophy of open source?
Re: (Score:3)
Plans to make QT a real community project already existed before Stephen Elop was made CEO of Nokia. And I would be very happy to see 3rd parties developing big chunks of QT - that would mean it can survive without Nokia.
Re: (Score:3)
Plans to make QT a real community project already existed before Stephen Elop was made CEO of Nokia. And I would be very happy to see 3rd parties developing big chunks of QT - that would mean it can survive without Nokia.
QT would have no problems without Nokia. It's the "with" part that people are worried about. And never so much as now that there's another bigger "with" involved.
Re: (Score:3, Insightful)
"There will be no distinction between a Nokia developer or third-party developer." becomes "Develop it yourselves you lazy bastards, but dont forget to put our name on it too"
Very wrong. Look at the list of maturity and status of Qt modules [nokia.com]. Nokia still is ready to maintain a huge percentage of Qt. They simply deprecated stuff because they think that other alternatives are better (eg. ditch Phonon because there is QtMultimedia). The only piece that Nokia is not interested in maintaining and that the comunity is worried about, is QtSVG, because the alternative, the SVG support in Webkit, is considered too big/slow, or unsuitable for being LGPL only.
This is Qt development framewor
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Seems like Qt5 will be more buzzword-compliant, though
Anyone up for developing a Qt competitor?
Re: (Score:2)
yes, but then you can intermix QML and traditional Qt forms together which is a seriously good thing as you keep the productivity gains for the 80% of common or boring old functionalty and get to work the last 20% in less-rpoductive but mroe functional QML.
Unlike XAML where you have a choice of all or nothing.
Re:Ugh.... (Score:5, Interesting)
I came from a Gtk+ background, but am using Qt Quick (QML) in one project. The widget set as of Qt 4.7.2 is woefully anemic, but other than that, it seems like a general improvement over using C++ for the entire UI. At least 90% of user interfaces (averaged over the world's applications; there are a few very graphics-intense apps that bring down the average) do not need the marginal speed improvement you can get by using C++ instead of QML. Qt does a pretty decent job at making it easy to go between native C++ widgets and QML code, so C++ developers get to focus on the parts of the GUI that need performance.
What is in using QML for me? I get to offload most of the GUI development to a UX designer who is better at that sort of thing (and costs my employer less per hour of work). Then I get to focus on the novel and application-specific parts of the interface. I also get cleaner separation between those application-specific bits and the overall skin.
Re: (Score:2)
Couldn't agree more. I will be getting our designer lady a QML/QMLDesigner tutorial in a week or so. That way I'll be getting ready-made user interfaces, with relevant functionality already built in, and I can focus on providing data models and state management for the application as a whole.
Re: (Score:2)
I came from a Gtk+ background, but am using Qt Quick (QML) in one project. The widget set as of Qt 4.7.2 is woefully anemic, but other than that, it seems like a general improvement over using C++ for the entire UI.
My impression is that Qt Quick is another one of those things that's going to come full circle. First you go from a huge set of widgets (QWidget & decendants) to html/css (Qt Quick) and eventually you'll want to build the exact same widgets on top of that again for convienience. Oh well..
Re: (Score:3)
I'd rather having nothing. I'm using Qt to write C++ code not to be a Javascript monkey. Looks like the Qt are trying to make themselves irrelevant with statements like:
Actually QML is there to try to make it easier to develop apps by allowing people to declaratively define their UI and use minimal inline or external language for the binding. It's a perfectly sound practice, variants of which one can be found in various other GUIs, both in thick clients and web development. e.g. Flex,. XUL, XAML, JavaFX etc. For starters it means doing away with a vast amount of boilerplate, faster application prototyping, faster development build cycles, greater portability, less bugs ca
Re: (Score:1)
greater portability
Wrong, QML will actually be less portable especially when Qt5 will require at least OpenGL ES 2.0. Kiss goodbye any support for embedded systems without OpenGL support and yes there are many.
less bugs caused by programmer error
In what way?
I realise if you're too set in your ways to adapt that it might be easier to denigrate such efforts than appreciate their uses, but that's your problem not the platform's.
I realise that to you a bunch of buzzwords and bling bling might be important but for those of us writing real desktop and embedded apps where performance is critical, this change is mostly useless. Hell even the Qt Creator guys are admitting they will barely be using QML and mostly sticking to QWidgets. I
Re: (Score:2)
It's not about buzzwords. Declarative UIs with bindings are a pattern proven to work elsewhere and it will be proven to work in QT. It doesn't mean it is right for every application but it will do for a lot of apps either in full or partially.
Re: (Score:1)
So if QML is so great why do the Qt Creator guys admit they will barely be using it in the Qt5 version of Qt Creator? The reason is is because it doesn't provide nearly the benefit that is claimed otherwise they'd be pressing full on into QML.
Re: (Score:2)
You may as well demand Oracle write Netbeans in JavaFX, or Microsoft write DevStudio in XAML.
Re: (Score:2)
That's a silly argument. I don't think you're laying out all the widgets by hand all the time, right? You're probably using Designer to produce .UI files for most of your UI. Guess what: QML designer is pretty much the same thing, but gives you much more expressive power. The QWidget/QLayout systems has inherent constraints that cannot be worked around by simply expanding the API. They needed a brand-new paradigm, and they delivered.
All of the back-end functionality (models!) has to be done in C++ anyway, a
Re: (Score:2)
I don't mean to rain on your parade, but we are developing a lot of QML/JS code and the development time is a fraction of doing the same thing in C++. In addition, we are finding that it is easier to train web graphic designers to use QML then to teach programmers graphic design. There are a lot more JS programmers out there than there programmers who know and use C++.
We are also doing Windows Mobile Phone 7 development and XAML is a really good model. You still have to write code behind in C#. The model wo
Re: (Score:2)
As pointed out and as I have discovered during my own research into QML its feature set in 4.7 is pretty aenemic. If they can make it a carbon copy of the feature set of the Qt widgets, then it might be worth looking into
Re: (Score:2)
First of all, reimplementing most if not all Qt widgets in QML takes less code than original Qt widget implementations took, line-wise. And it's by a fairly large factor -- a reduction of 5-10 times. Just look at the Qt Quick Components for Desktop [nokia.com] -- it's pretty amazing stuff when you realize that a table view is about 500 lines long. For your reference, src/gui/itemviews/qtableview.cpp is 3000 lines long, and it's not nearly as modular and tweakable as TableView QML element.
The beauty and power of QML is
Re: (Score:2)
First Before you make sweeping comments, you should do a little research, because you are completely wrong. Hence the cowardly anonymous posting. The apps we developing are huge and run on some fairly light hardware. Turns out that QML is f..king fast and the few thing that aren't can be implemented in C++ and bound to QML. I don't believe you have done any testing. I think you are making this up. The data driven part of data driven apps in QML are implement in C++ you twit. That includes the XMLModel. Any
Re: (Score:2)
I think you didn't look at the code. First of all, QML is NOT Javascript. It is a declarative language that integrates seamlessly with Javascript. As for efficiency: I'd beg to differ. There's nothing inherent in the declarative framework that would make it less efficient than QWidget. QML has expressive power that makes legacy frameworks look almost silly. QML comes with a lot of demos. Try implementing some of them using out-of-the-box pre-QML APIs and you'll understand.
The QLayout system is a complete ni
Re: (Score:1)
I think you didn't look at the code. First of all, QML is NOT Javascript. It is a declarative language that integrates seamlessly with Javascript.
More accurately, QML is Javascript with extensions.
As for efficiency: I'd beg to differ. There's nothing inherent in the declarative framework that would make it less efficient than QWidget.
And yet with a simple search of "QML slow" you can find all sorts of examples of QML running slow. All sorts of people are seeing lagginess, etc in QML apps. The best the Qt people have shown have been little toy examples where there may be no noticeable difference. Get back to me when they have a full blown app that has lots of intensive visualization and show me that it has no efficieny issues.
QML has expressive power that makes legacy frameworks look almost silly.
Examples? It really means little to hear people throw out
Re: (Score:2)
QML has expressive power that makes legacy frameworks look almost silly.
Examples? It really means little to hear people throw out buzzwords and provide no examples of how it is more this or that.
Look at any of the demos that come with it. Say the corkboard [trolltech.com]. Then implement using "bare" Qt.
I have ported a database-driven application to QML, and I can't feel any speed difference between the declarative UI rendering the views and the QWidget views. There are perhaps problems when too many things are moving about at once, but I'm not trying to do that. The only motion is in following the mouse and doing flicks, and this performs as it should.
Re: (Score:1)
Look at any of the demos that come with it.
You mean all the little toy demos that aren't even remotely similar to the needs of a full blown desktop app? I'll believe it's so great when Qt Creator is implemented fully in QML. Oh wait, that's not going to happen as they admitted they will only be using it very sparingly. Since they don't eat their own dog food, I don't buy the hype.
Re: (Score:2)
Umm, qmlcreator is implemented in QML. Qt Creator is such a simple thing when it comes to visual design that doing it in QML will not expose any performance issues. It'll still use the same editor widget etc. This actually gives me idea to try it out, I'd love to see the reduction in code size. It may turn out to be a quick job for the main window, too.
Re:KDE5 (Score:4, Informative)
KDE5 will not break the world like KDE4 did. Just as Qt5 will not break the world.
http://aseigo.blogspot.com/2011/05/relax.html [blogspot.com]
http://aseigo.blogspot.com/2011/05/qt5-kde5.html [blogspot.com]
This will kill KDE (Score:2)
Re: (Score:3, Interesting)
Re: switch to xfce (Score:2)
Hi.
I am a potential new linux user and my initial specialty/focus will be on the UI side. I have been considering looking into xfce as well. Do you think it's the new dark horse UI behind Gnome and KDE?
Re: (Score:2)
Re: (Score:2)
I enjoy xfce4 but am happy with KDE4. It's not a dark horse, just another alternative. On a standard PC I would recommend Kubuntu, but on a netbook it's a trade-off time vs speed. If you want something that just works then install Kubuntu, though it's a bit heavy and slow, but if you have time to tweak (make sure you install ROX) and want the extra horse-power out of it then install Xubuntu. It is not that one is better than the other, it's just a trade-off. They are both great.
Phillip.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
There will be no distinction between a Nokia... (Score:1)
> There will be no distinction between a Nokia developer or third-party developer.
Or indeed not being a developer at all.
Is the lock in that strong? (Score:3)
Re: (Score:3)
The annual (linux) Meego conference is in a few days' time, in San Francisco. Google News (search) reveals that the Nokia N950, the successor to the N900 will be _probably_ be announced at this conference.
Nokia has never backed-off its support for Meego. Well, okay they have hyped and now focused development resources towards their M$ partnership, but to the extent possible given their current business strategies, they still support their prior open-source OS strategy. In other words, they haven't really ba
Re: (Score:2)
I guess people are voting with their feet - by not buying WP7 :)
We'll see what happens, I think WP7 will continue to bomb even after the $1bn bung from MS runs out, and then Nokia will at least have the opportunity to ressurect itself with its old ace card, maybe beefing it up for non-phone systems. The danger is that, good though Meego is and could be, Android will steal all its market before it has a chance to shine. That's a problem they'll have to deal with while they attempt to flog WP7 devices.
Re: (Score:3)
Re: (Score:2)
The vast majority of user interfaces spend more time waiting for user input than they spend drawing to the screen. Of course, users notice redraw time more when they are the ones waiting. But I've used Qt on a small device (a several-year-old cell phone application processor), and the things that made that UI slow are the animations that were chosen for the UI -- animations that are drawn by the CPU and GPU using compiled code, but with durations that were a little bit too long for impatient users like me
Re: (Score:2)
Then kill that performance with JS?
You surely save a lot of CPU cycles on laying out 100k times per minute all those views and dialogs painstakingly hand-coded in C++. Or wait... may I suggest to optimize what really needs to be optimized, and enjoy the productivity boost in creating the rest, not to mention separation of tasks between UI design and application logic programming?
Re: (Score:2)
may I suggest to optimize what really needs to be optimized, and enjoy the productivity boost in creating the rest, not to mention separation of tasks between UI design and application logic programming?
Of which you can already do now without the need of QML and its overhead. Plus the Qt people keep trying to skirt around the performance issues when people kept repeatedly asking about it and considering how many posts you get about poor performance with QML apps through simple Google searches I can see why. Factor in how many custom widgets people use in desktops apps now and I can't possibly see most people wasting the time and effort to rewrite in QML.
Re: (Score:2)
Porting a QWidget to QDeclarativeItem is so easy that it could be considered a janitorial task in many projects. Plenty of simple custom QWidgets can be reimplemented in QML with a significant drop in code size, so there's actually a good reason to do that. Especially if you have a designer on staff who got Qt Quick training and can provide you with an "endless stream" of custom, appealing widgetry.
There's nothing architecturally wrong with QML. The current implementation surely has performance corner-cases
Re: (Score:1)
Porting a QWidget to QDeclarativeItem is so easy that it could be considered a janitorial task in many projects.
Well then why haven't you ported all the QWidgets over for us by now? It's so quick and easy, right?
Plenty of simple custom QWidgets can be reimplemented in QML with a significant drop in code size, so there's actually a good reason to do that.
That's great if all you ever used were "simple" QWidgets. Many people rely on much more than "simple" widgets for real apps.
The current implementation surely has performance corner-cases, just like early Qt 4.x series had, especially before 4.4.
Thus making it unusable for people who need high performing apps. Most people aren't going to rewrite things in QML just because they are promised that years down the line it will stop being laggier and slower than their current QWidget-based programs.
The performance issues will be worked out, there's no fundamental reason why QML should perform worse than a QWidget-based ui.
Sure, if we ignore the overhead o
Re: (Score:2)
The performance issues will be worked out, there's no fundamental reason why QML should perform worse than a QWidget-based ui.
Sure, if we ignore the overhead over interpreted code.
There's no "interpreted code" anywhere in QML. Whatever parsing there is, is done only once. Javascript is executed by a decently performing JIT-ting runtime -- same one that powers WebKit. Instantiating a QML element does not AFAIK cause any textual source code to be parsed or JIT-ted more than once. Surely there will be some overhead due to parsing QML at application startup, but this can be tweaked by doing lazy instantiation via the Loader.
Re: (Score:1)
Surely there will be some overhead due to parsing QML at application startup
So that doesn't explain why QML apps are also laggier while running. Also, I like how you ignored everything else I said. If porting all the QWidgets already written to QML is such an easy task then you have all of the ones that ship with Qt now ported over by next week, right?
Re: (Score:2)
Direct porting to QML means that the code still stays in C++. One could start porting QWidgets by designing a small shim class that interfaces the exposed QWidget API to the underlying QDeclarativeItem APIs. Most of what the shim would do is just translating event data types. I've done it as a proof of concept, and there's nothing to it. You literally derive from a WidgetShim instead of QWidget, and it "just works". There's no difference in performance, since the widget code is exactly same, and the shim is
Windows Phone 7 and Qt... (Score:2)
Why exactly are these two things related? Qt is a completely different development line from WP 7, it's a windowing toolkit not a mobile OS. Show me some good news about MeeGo, and I might, just maybe, get a bit excited.
Sure, you could go on about how Qt is at the foundation of MeeGo, but it's at the foundation of lots of other things too, like KDE amongst others. Good news for Qt does not imply good news for MeeGo. In fact, possibly quite the opposite, as I can imagine a scenario where Nokia had left o
Re: (Score:2)
Re: (Score:2)
Give it to Samsung! They are already streets ahead of Nokia when it comes to hardware, give them Meego and I can see them becoming the number one handset manufacturer.
Phillip.
Re: (Score:2)
Samsung doesn't want to work with MeeGo, at best they'll meet up at the Linaro level. LG has already hopped on the handset working group.
Re: (Score:2)
Best GUI library for C++ (Score:1)
If you're writing software in C++ that's portable, which GUI library would you use at the present time?
Re: (Score:1)
Or more options here [dwheeler.com]
Re: (Score:3)
Good call... so in other words, something use something like http://www.wxwidgets.org/ [wxwidgets.org] for cross-platform development while still hooking into native widgets?
Re: (Score:2)
Re: (Score:3)
I've used Qt on OSX. It works fine. And Qt looks native on all platforms so I have no idea what you're talking about...
Re: (Score:1)
Re:Best GUI library for C++ (Score:4, Informative)
> The only way to do it right is to use the native controls, which QT DOES NOT.
I think you have not used Qt for a long time...
http://en.wikipedia.org/wiki/Qt_(framework)#Use_of_native_UI-rendering_APIs [wikipedia.org]
Re: (Score:2)
Actually no. Take a look at what they say [nokia.com]:
They are saying they are using the native drawing layer, not the native controls. There is a huge difference. The last QT App I used still didn't support OSX services. Which it would if it were using native controls.
Re: (Score:1)
Qt doesn't use native widgets. They never have. What they have recently changed is using the native drawing APIs. That is not the same thing.
Re: (Score:2)
It doesn't "fake" the look. It uses the visuals drawn by native APIs on both Windows XP and up, and on OS X. You can't enable an OS X look in KDE simply because Qt doesn't have the code that implements the look, it politely asks the Cocoa or Carbon API to do the drawing for it.
Use of native controls is something I shun because as soon as you get a lot of them, you run into serious performance issues. Try having a thousand native-widget OS X buttons in your window, and see how fast they respond [nokia.com]. By dropping
Re: (Score:1)
If by "runs native" you mean it has in the last couple of years moved to use the native drawing APIs of the platform, yes, but it doesn't use the native widgets if that is what you are trying to imply. And for the longest time Qt just faked the native look with themes before using the native drawing APIs.
QT5 should drop MOC and adhere to standards (Score:1)
Re: (Score:2)
Re: (Score:2)
Dynamic dispatch is pretty fundamental in event driven UIs, and not sure if C++ can really provide such a concept. Thats why we need more dynamic languages like JScript/Python/Objective-C/C# for this type of programming.
I'm sure there are things C++ is good for, but its not something as dynamic as UIs.
Re: (Score:3)
We as in who? The "template metaprogramming" weenies who could not understand for a decade why C++ is a train wreck?
Don't bother; "we" the practical developers creating real-world maintainable software don't need you on our projects.
Re: (Score:3)
It's not even about template metaprogramming. Template metaprogramming simply does not provide several facilities that are make-or-break for language binding generation. C++ does not have built-in facilities needed by binding generators, this has nothing to do with Troltech/Nokia's developers "ineptness". Guess why swig still exists? Hint: because whoever designs C++ lives on a little cloud-9 where you don't interface with anybody who doesn't use C++. It's a basic deficiency of current C++ spec, and there's
Re: (Score:2)
because whoever designs C++ lives on a little cloud-9
You could have put the period here. They are also oblivious about such bleeding edge innovations as shared libraries and standardized ABIs.
Re: (Score:1)
We as in guys who don't want a stupid non-standard moc-to-cplusplus-precompiler messing around our make scripts.
And if you say C++ is a train wreck, perhaps you should take a look at how C++0x has improved things.
Qt has forced this "our way or the highway" mentality on developers. Want signals and slots? No, you cannot use your custom template implementation that would make things much easier, you need to do it via the MOC. Properties? The same thing. And don't forget that if you read the code and do your o
Re:QT5 should drop MOC and adhere to standards (Score:4, Informative)
C++ simply does not provide the introspection needed for a major application development framework. If it did, you could drop MOC. The way it stands, moc basically generates introspection tables because the out-of-touch [expletive deleted] folks who design C++ couldn't be bothered. That's my take on it.
Every time you interface C++ code with any sort of an interpreted or JIT-ed language, you have to generate "bindings" using an external tool precisely because C++ lacks facilities for code to know about other code. Qt folks were nice enough to maintain such a tool themselves and to make it a core part of their process. I don't consider it a bad thing. QMetaObject system makes it fairly easy to expose QObjects to any other language that's either interpreted or JIT-ed.
Re: (Score:2)
Why, it can be done with some template classes, especially with variadic templates accepted into the standard this year. Except, the declaration syntax would be far more ugly, the compilation time would increase by orders of magnitude, and if you screw up, the error messages won't be much less arcane than what you get from moc-generated code.
offloading dev costs? (Score:1)
Why is Nokia spending money doing this? (Score:2)
As much as I'd like to believe that it's because they are good people doing good things, why are they putting money into this, and how long can we expect them to keep doing so?
Re: (Score:1)
As much as I'd like to believe that it's because they are good people doing good things, why are they putting money into this, and how long can we expect them to keep doing so?
There is a rumor about this. Some people thought that it would be possible to add S40 support in Qt. I thought that S40 phones are too small and cheap to run powerful apps, and the demand for applications for this platform is quite small, but... Stephen Elop and Mary McDowell visited Qt headquarters [nokia.com]. McDowell is the head of "mobile phones", which is the feature phone (or "dumb phone") division in Nokia. Given that Windows Phone is only targeted at high end, some of the market space that Symbian covered has
Re: (Score:3)
it does seem strange that Nokia sold the rights and licenses to collect revenue from customers yet retained control of the Qt development with little to no form of income from it. But then there's this poison pill they agreed to when p
Re: (Score:2)
You're paranoid. Plus the poison pill agreement is not relevant anymore now that Qt is under the LGPL (it was drafted before the license change). Check the work on open governance for Qt.
Re: (Score:2)
LoB
Re: (Score:2)
To learn from the former Trolls how to create great software. The framework is important, but so are the people working on it, and how they get things done.
I haven't been worried about it (Score:2)
I've written it off as more or less completely irrelevant
Re: (Score:2)
The future of Qt (Score:1)