Rumour: Nokia to be split?
I hope that the Qt will be purchased by Intel
Now that would have been great, although Intel is so mighty they could easily develop a software development framework from scratch. I’ve sort of always wondered why they haven’t done that already, they do have many amazingly powerful development tools, but not a complete solution.
…and that that would be bad for Qt
<sarcasm> We all know Nokia is the best thing that ever happened to Qt, equal only to the introduction of QML, which we all know had nothing to do with Nokia. </sarcasm>
There is however a number of ways Nokia’s woes can affect Qt, as the controller and funder of most of the development force behind Qt, being strapped for cash can have multiple negative effects like reduced research and development, reduction of workforce and so on.
As nice as it would be to sell Qt to someone else, I don’t see that happening, as Nokia would probably have a hard time selling it at at the price they bought it, and the amount of money Qt could be easily sold for is not all that much to make a difference, so I don’t really see Nokia letting go off Qt, they bought it when Nokia was in its peak value and could afford to spend a preposterous amount of money on Qt, more than enough to build… like several software SDKs from scratch.
Nokia bought Trolltech in an attempt to counter the momentum of iOS and the looming on the horizon Android, and in 2008 they held like 60% of the mobile market, which could potentially have resulted in great success, but somewhere along the way their plan did not work. The little market Nokia has left is all betting on windows mobile, with MS development tools being the development environment of choice, Symbian is a done deal, BlackBerry is slowly and surely dying, there is no indication of Android or iOS being officially supported, and the little community work done by volunteers isn’t going anywhere, leaving Qt, purchased with the intent of extending it into the booming mobile market stranded back where it used to be 5 years ago – desktops, with the majority of development efforts focused on QML which itself tailored as a mobile app development tool.
All in all, the situation of today is the result of a long series of missteps, there doesn’t seem to be possible for Nokia to have played their cards any worse, and being under the control of such a poor decision maker has its inevitable effects. Nokia has given a direction for Qt that IMO is far from optimal, and that was to be expected.
Before Feb 11, 2011, Qt was the framework for targeting the OS with most market share, Symbian. And with Meego on horizon, Qt on mobile had promising future. But all that is gone. Qt on mobile has become the framework for a collection on dead / struggling platforms (Symbian, Meego, BB). Android and iOS ports are not official. We don’t know if they would be successful in the end. I’am hoping that they would really come off. I’am hoping that Meltemi and BB10 becomes hugely popular. That would give Qt on Mobile a big thrust.
I don’t think direction of Qt under Nokia is wrong. Nokia has given us Qt mobility, lgpl and Qml is a good addition as a means for good UI, then c++11 in Qt 5.0. So far good.
Wrong. Due to beeing fully hardware accelerated Qt Quick will run way smoother on such devices.
Windows Phone 7s problem is not (only) the lower-end range, but rather the higher-end range (not supporting high resolution displays and cameras, not supporting multiple camera interfaces, not supporting multi-core CPUs, not supporting memory cards, …).
You are not competitive in terms of features in the high-end market, you are not competitive in terms of price in the low-end market and you have to heavily subsidize in the mid-range market (free XBox, trading for Symbian, …) to be actually competitive.
Just compare the PureView or the N9 to the Lumia series. And at the end of the day one is astonsihed that the latter devices do not sell and your smartphone division is generating huge loss on a constant basis.
Oh yes, I have no doubt Qt Quick runs on a hardware accelerated interpreter and JS engine. Just as much as I have no doubt this is a Qt Quick exclusive feature and WP7 takes no advantage of hardware acceleration whatsoever, making it infinitely worse than Qt Quick.
One thing is sure thou – those tiny, low resolution displays will provide a breath-taking, jaw-dropping hardware accelerated QML experience.
Nokia managed to drive Symbian from a market leader to non-existent, and Maemo couldn’t even make it to the market in a significant volume, we have every reason to believe in the imminent success of Meltemi.
After all that irony, it would seem that your affiliations continue to cloud your objectivity. But it is understandable, the ONE THING I don’t understand is why no body is banning me from this forum? After all your beloved Nokia has censored out my blog comments…
Got to love the hypocrisy, playing it all liberal here in the forum while communism is raging at the LABS and BLOG comment area.
Being critical or being misguided is no reason for banning on this forum. Nothing in the TOS [en.gitorious.org] would justify that. What happens on other blogs, forums (operated by Nokia or not) is not the responsibilty of anyone here.
Note that Lukas is, AFAIK, not affiliated with Nokia other than being another developer working with Qt. The people on this forum who are, are recognizable by a green Troll badge under their name.
Having said all that: I guess everyone gets your point that you think that Nokia’s management is bad and untrustworthy, that Qt is heading in the wrong direction and that QML is a misguided attempt to push a propriatory technology that doesn’t hold a candle to using C++, or something along those lines. Fine. You are entitled to that opinion. Now, if you don’t mind, shall we go back to our work? Perhaps you could spend the energy that you put in writing all those long posts here into something more productive? You could start research into creating a C++ API for the features like Scenegraph that you seem to like, or perhaps you could search for alternatives outside of Qt if you don’t think it suits your purposes anymore?
#offtopic, deterred by those last two personal posts
“A fool’s mouth is his undoing.”
So insults are allowed in quotation form?
@Andre – I’ve been looking into many alternatives the last week, and my involvement in this place is all about ending it in a natural way, just like a car doesn’t stop in an instant (unless you crash into a wall) my momentum needs to wear out, and I feel obligated to do anything in my power to sway Qt in the right direction, as my suspicions the push of QML has nothing to do with technical necessities but corporate politics get more and more confirmation. Don’t get that concerned with my long posts – I am quick at typing, and the time “wasted” on expressing my opinion is, at least IMO quite a better investment than the time I truly wasted, spent on learning and promoting Qt with the false idea it will remain dedicated to native C++ programming.
What happens on other blogs, forums (operated by Nokia or not) is not the responsibilty of anyone here.
So it is just an amazing coincidence all my censored comments suddenly popped out, coincidentally after that last forum post, surely it was that “anyone here” who is not responsible and who didn’t read my post and got embarrassed or told to un-censor comments from my IP? Here is a news-flash – I am not as stupid as you appear to perceive me to be, and I wasn’t born yesterday.
And if my rant can make my censored posts get uncensored, then it must work, so if it can, directly or indirectly contribute to returning development attention back towards native APIs, even a tint bit – then it is time well spent. I am not even pushing to deter Qt from developing QML, just to leave developers the choice not to use it without having to give up on every major contribution to Qt done after the acquisitions.
And it is not like I am pulling your hair to get you off your work – My my crusade against Qt’s management is a product of my own will, just as your crusade to defend it is a product of your own will, so feel free to get back to your work at any time.
MODs: Feel free to move the last three posts, this one included, to that other thread, since none of those regard Nokia.
Nokia tried a lot of development platforms in the recent years:
Symbian C++ (CodeWarrior) for Symbian OS
Symbian C++ (Carbide.c++/Eclipse) for Symbian OS
GTK+ for Maemo
Qt for Meego
Visual C++ (only for OEMs) for WP7
No one was/is really successful (in the last 1-2 years). Nokia try/tried to jump from one to other. This can confuse the developers (and the consumers too)! I don’t like to learn completely different development environments year by year.
I think that the most successful would have been the Meego/N9 line.
The N9 was/is a really good phone. But because the selling dates are not so good (because of Nokia’s bad marketing decisions), this line will be disappear.
I can’t see the future of Qt…
@temp: You seem very passionate about Qt and yet very disapointed, because of Qt moving route.
Some people fear that they are investing their time and energy, and that Qt may disapear, and will have to start over with something else new and diferent. I think we shouldn’t worry too much about the future and live for the present. Qt isn’t going anywhere soon, even if Nokia would drop it, Digia is still working on it, and a lot more companies and the open governance. And don’t you worry about not having big Nokia around to support it, did you forget that all it took was 2 trolls to start it ?
One good example of what I’m trying to say is OpenGL, the old fixed pipeline was easy and pleasent to work, but that will be gone soon and we will have to learn the new hard way, the programming shaders. More time and energy to start again and learn all the new things, because they are not even backwards compatible.
And about Qt, even if it was moving to some route that pleased you, sonner or later you would have to spend lots of time and energy learning new stuff, because in the IT industry things change very fast. C++ just have changed to a new level. For the moment, do you see any feature about Qt that has been removed that you really need it ? Because Qt widgets are still there, and C++ is still there. And nobody told they were going away. When OpenGL masters said fixed pipeline was going to be deprecated, they gave some years and some compatibility versions for people to learn the new way.
If a day comes when Widgets and C++ are to be deprecate from Qt, they are not going to disapear in a day, and we will have time to learn the new way, or if we don’t like it just move away and learn new things. Meanwhile, since all the goodies are there why not stick a round for the moment, make peace with Qt and keep on enjoying it ? That’s just my humble opinion.
@john_god – Digia is still “working on it” but that work is concerned mostly by bug fixes and commercial support, I don’t see Digia rushing to implement a native C++ frontend to Qt Quick, which is what Qt needs.
OpenGL IS backward compatible, and the introduction of a programmable pipeline did not enforce a new language standard, virtual machines and interpreters, glue code and all that nonsense, it just offered more flexibility while retaining the good old C style syntax and API.
As for the rest, there is an ocean of a difference between “something is still supported” and “something is actively developed and improved on”, and the fact of the matter is a native frontend to Qt Quick and the SceneGraph is totally doable, but then again, that would give the option not to use QML, not to have glue code, nor the overhead of interpreting and a JS VM, which for some reason Nokia thinks is a bad thing. QML has NOTHING TO DO with improving technology, and even a child can tell you that you will get superior performance and efficiency, combined with deeper access to APIs by keeping to a native development pipeline. And if QML was about improving technology, the logical move would have been to offer it as an alternative to C++, so that people could compare the QML and C++ frontend to Qt Quick and decide whether they want the overhead of QML or whether to keep it native, but there is no native frontend to use the C++ backend that sits behind QML, to deliberately make it impossible to compare the two and realizing native development is superior in most of the aspects.
… which is what Qt needs.
I think that therein lies the point of contention. While you feel (and quite deservedly have the right to believe so) that this is completely and totally necessary (for whatever reason anyone chooses to argue,) the vast overwhelming majority of developers and users would appear to disagree, simply by the merit of how many developers have happily jumped onto the QML train and are reaping the benefits and rewards of it.
Please don’t get me wrong, as I’m not criticizing your thesis. I’m just pointing out that, for no matter what reason that there isn’t a C++ front end to the QML-based stuff, generally people are ok with it and are flexible enough (and content enough) to adapt.
With that said, if you can rally the troops enough to get a groundswell of support for the types of features you desire, then I’m sure that developers — both commercial and private — would jump on the bandwagon and start pushing forward on those features. But, unfortunately, the fact of the matter is that developer resources are limited and tend to be thrown at things that are viewed as having the highest priority.
There can be a valid arguments made for wanting a C++ front end, and you have been voicing those arguments very clearly. (Kudos to you for that!) But, so long as the big majority of designers and developers are ok with using QML as an alternative, then there probably isn’t going to be a lot of attention given to those arguments, no matter how well-spoken or loudly-shouted they may be.
That’s unfortunate sometimes — especially when you’re passionate about something as you obviously are — but sometimes it can’t be helped.
The holdup to C++ bindings has never been some closed-door cigar-smoking panel of executives somewhere making decisions on what the proprietary or non-proprietary nature of the toolkit will become, but instead has been from the global acceptance and adoption of the QML solution that the Qt developer community has adopted, backed, and continued help design, shape, and implement.