Nokia Closing Australian Office, Looking To Sell Qt Assets 125
An anonymous reader writes "One day after word leaked out that Nokia is shutting down its Qt Australia office, which is responsible for Qt3D, QtDeclarative, QtLocation, QtMultimedia, QtSensors, and QtSystems, reports are beginning to surface that Nokia is trying to sell off all Qt assets."
Seems like selling itself to Nokia wasn't the best option for Trolltech after all.
Re:For better or for worse... (Score:4, Interesting)
And hopefully this means that Qt will go back to focusing on the desktop widgets instead of QML and the inane pipe dreams about mobile devices that never came to exist.
Still a great toolkit despite Nokia (Score:5, Interesting)
Maybe SUSE (Attachmate) can buy it, or even better Cannonical. SUSE could keep it going but Cannonical is trying to develop a toolkit from the ground up for Unity3D based on NUX, but it is really terrible compared to Qt and it will take them 5+ years to catch up. Forever in this business. It would make much more sense to move Qt in the direction they want to go.
Re:For better or for worse... (Score:5, Interesting)
Pretty strong and incorrect comment from a coward.
Qt largest growth sector is embedded systems and QML Is the driving force behind this market. You cannot get the performance from Widgets that you can from QML objects (Well you can if you rewrote the widgets in a light weight framework like QGraphicsView or SceneGraph, but then you would essentially have QML.)
I don't know where you get your facts, but QML behaves very well in highly animated GUIs on fairly low end embedded hardware. The fact that it is backed up with a highly optimized SceneGraph engine that removed the overhead of the QGraphicsView engine makes QML even better performing.
The comment above about Digia is greatly misleading. Digia focuses on the commercial license market which is a legacy business. The growing embedded market uses the LGPL version and gets support from the open source community. Companies like ICS and KDAB are growing at a very fast pace servicing this market. Digia has not been able to transition well to the embedded space.
Re:I hope Google gets Qt (Score:5, Interesting)
Re:For better or for worse... (Score:4, Interesting)
As for embedded systems, if there is enough computational power to display a GUI, I really do not see how exceptions are problematic.
probably a good thing for Qt (Score:5, Interesting)
Over the last few years, whenever I looked at a changelog for a new release of Qt, I noticed quite a bit of of work was being done to support Symbian or Meego. When I went to their annual conference a couple of years ago, some of the stuff they were showing off (namely, basic UI control widgets for QML) seemed to be focused on Symbian or Meego first and maybe other platforms later. Meanwhile, I noticed that some releases of Qt (especially around 4.6.2) had some surprisingly bad bugs that I wouldn't have expected in the past. I wasn't alone. A friend of mine at Nokia doing Mac development with Qt admitted as much. The whole thing made me think that far more resources was going into getting Qt support for Nokia's platforms at the expense of Qt's traditional desktop platforms. That's an uncomfortable feeIing to have when you're a software firm and you're paying Nokia (and now Digia) for commercial support for the toolkit. I'm hoping that what's going on now will refocus Qt development.
Re:Nokia -- why? (Score:5, Interesting)
What happened is that Microsoft managed to get an ex-Microsoftie into the top job who then eliminated a major competitor and turned them into the biggest supporter of the Microsoft platforms.
And with Nokia being all about Windows, Qt has no place at Nokia anymore, hence the decision to get rid of Qt.
Comment removed (Score:5, Interesting)
Google can buy it, give it to Stroustrup (Score:1, Interesting)
I think this is great. The devs got paid $135 million for all their hard work, from a big, stupid company. Now, Nokia will probably sell it at a low price. Google as an act of generosity could buy it for a low price, and give it to the C++ committee.
Re:For better or for worse... (Score:5, Interesting)
You seem to be wrongfully blaming deficiencies in Qt's implementation on the langauge
I was originally replying to a post that claimed Qt was the "best" toolkit for writing "high quality" C++ programs. Qt uses error codes, not because error codes are a good thing (they are not), but because Qt is a C++ toolkit and C++ makes anything other than error codes unreliable. How is that an unfair criticism?
I've written numerous pieces of complex software with Qt using exceptions and have never seen an exception fail to be caught or ever let errors go unchecked
Except that preventing exceptions from crashing your program in C++ means preventing some exceptions from propagating -- and basically forces you to create programs that do not handle certain errors. In C++98, you could just risk a double exception fault, but it was considered bad practice; in C++11, you can't even take that risk, and so your destructors either have to handle the error properly or you need to find some other way to signal the error (or else let it go unhandled or just quit). On some level, you are either not using exceptions at all or else you are allowing some exceptions to be ignored -- that's a reality of C++ exception handling.
I've used tons of crappy Java and .Net
Did I say that Java or .NET are better? In all of these systems, exceptions could have been done better -- for example, by not destroying the stack before the exception handler executes. Java won't cause your program to abort when exceptions are thrown, but Java will cause exceptions to be "forgotten" under some circumstances:
That is not much better if you want "high quality" software.
You might want to update your C++ hater points beyond what you read on yosefk.com or other lame whiner sites.
Lame whiner sites? I programmed C++ for a decade, and I still have to write C++ code sometimes. My dislike of the languages comes from experience, not from some website. Error handling is just one issue, one that I think is very much relevant if we are going to talk about "high quality" software. Programming in C++ requires knowledge of the long list of undefined behavior, the long list of patterns that have to be used to avoid that behavior (which hardly anyone deviates from, except for novices who have not yet learned the patterns), and debugging is as much about correcting bad program mechanics as it is about correcting bad program logic (and the majority of C++ code is not low level code).
Yes, I know, programmers should just follow best practices; if that is the case, why not just make those practices standard, and create a special statement to disable that behavior? Why are we forcing programmers to explicitly say, "I do not want this program to crash," when we could be forcing them to be explicit in situations where they do want to write potentially unsafe code?
Re:Nokia -- why? (Score:5, Interesting)
Re:For better or for worse... (Score:5, Interesting)
That hasn't stopped GTK+ from working on all three platforms.
Define working :)
GTK+ apps look out of place on Windows, even more so on Mac. In addition to that, Qt just integrates a lot better into the native tool chain (e.g. Visual Studio, Xcode). Prior to being bought out by Nokia, Trolltech were charging $1500 per developer, per platform for Qt. And Trolltech were profitable! It is *that* good a toolkit. It's benefited immensely from being backed commercially and it shows.
Will this continue after Nokia bails? Will the pace of development slow, to the extent that it no longer integrates as well with new tool chains and platforms? That is an unknown and I really hate unknowns ...