Nokia Closing Australian Office, Looking To Sell Qt Assets

← Back to Stories (view on slashdot.org)

Nokia Closing Australian Office, Looking To Sell Qt Assets

Posted by Unknown on Wednesday August 1, 2012 @02:51AM from the this-isn't-funny-any-more dept.

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.

125 comments

Min score:

Reason:

Sort:

For better or for worse... by Kensai7 · 2012-08-01 02:54 · Score: 4, Insightful

This might be a good thing for Qt. It is the BEST C++ toolkit for many high quality applications. It was being drudged behind Nokia's anemic policy regarding where to head with a mobile OS. Let's hope it doesn't end to Oracle. :p

--
"Sum Ergo Cogito"
1. Re:For better or for worse... by Desler · 2012-08-01 02:59 · 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.
2. Re:For better or for worse... by CadentOrange · 2012-08-01 03:07 · Score: 3, Informative
  
  Having used both, VCL has nothing on Qt. It also doesn't hurt that Qt is free and cross platform while VCL costs a fortune and has only recently gained OS X support. However now that Nokia appears intent on offloading Qt, I'd worry about Qt's long term future.
3. Re:For better or for worse... by Anonymous Coward · 2012-08-01 03:07 · Score: 0
  
  Does that toolkit have anywhere near the functionality of the full Qt suite? I don't know much about it, but after a quick google I seriously doubt it.
4. Re:For better or for worse... by DeathToBill · 2012-08-01 03:07 · Score: 2
  
  Oi, get your beard cut!
  
  --
  Slashdot - News for Nerds, Stuff that Matters, in ISO-8859-1 Has just realised that beta makes this signature redundant
5. Re:For better or for worse... by Anonymous Coward · 2012-08-01 03:09 · Score: 1
  
  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.
  Nooo... QML (once the desktop components are finished) are the best thing to happen to Qt in a long time.
  Hardware accelerated, easily animated, interpreted- It's really slick and much easier to create custom widgets with.
6. Re:For better or for worse... by Anonymous Coward · 2012-08-01 03:12 · Score: 0
  
  Yeah and completely worthless for any real desktop application beyond toy apps, due to QML's sluggishness, or creating some Metro fart app.
7. Re:For better or for worse... by Desler · 2012-08-01 03:16 · Score: 1
  
  They could have made widgets hardware accelerated and easily animated, but that would hav required 'hard work' and it's more fun to just shove out new crap instead. Luckily, Digia seems to have people that realize what the real needs of the vast majority of Qt developers are even so they continue to fix and improve widgets as the Nokia guys were having fun in their QML circle jerk into irrelevance.
8. Re:For better or for worse... by Anonymous Coward · 2012-08-01 03:18 · Score: 5, Funny
  
  I hope the Raspberry people buy it.
  Then they can call it Qt Pi.
9. Re:For better or for worse... by killmenow · 2012-08-01 03:22 · Score: 1
  
  fresh outta mod points but that was funny.
10. Re:For better or for worse... by Anonymous Coward · 2012-08-01 03:23 · Score: 0
  
  Having a great toolkit that makes highly efficient applications and is source compatible on tons of operating systems? Where is the problem exactly? Oh, you must be one of those Java 'programmers'.
11. Re:For better or for worse... by Stele · 2012-08-01 03:24 · Score: 2
  
  -1 Ignorant
12. Re:For better or for worse... by betterunixthanunix · 2012-08-01 03:29 · Score: 3, Informative
  
  Not really; look at the state of exception handling in C++ and get back to me about "high quality" software. In fact, Qt's own documentation says this:
  
  Exception safety is not feature complete! Common cases should work, but classes might still leak or even crash.
  And,
  
  Qt itself will not throw exceptions. Instead, error codes are used.
  
  http://qt-project.org/doc/qt-4.8/exceptionsafety.html
  
  Which is not to mention the incoherent uses of exceptions and error codes in the C++ standard library.
  
  --
  Palm trees and 8
13. Re:For better or for worse... by Desler · 2012-08-01 03:35 · Score: 1
  
  Yes, and? It's still less annoying than checked exceptions in Java. Also, Qt runs on embedded platforms where exceptions aren't a good choice for use so error codes is the pragmatic choice they made.
14. Re:For better or for worse... by glebovitz · 2012-08-01 03:38 · 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.
15. Re:For better or for worse... by betterunixthanunix · 2012-08-01 03:41 · Score: 3, Interesting
  
  The problem is that "high quality software" should handle errors -- it should not crash when an error occurs (in the worst case, it should gracefully shut down), and it should not ignore errors. Error codes are fine as long as you actually handle them, but in practice the effort required to check the return value of every function call (and you think checked exceptions are annoying?) leads to some errors not being detected or handled. That is why exceptions are good in theory; but if in practice, an exception can cause a program crash even when there is an exception handler waiting to catch the exception (this is the case in C++), then they are not a good way to deal with errors.
  
  As for embedded systems, if there is enough computational power to display a GUI, I really do not see how exceptions are problematic.
  
  --
  Palm trees and 8
16. Re:For better or for worse... by Anonymous Coward · 2012-08-01 03:46 · Score: 0
  
  I get my 'facts' from actually using it and from Qt developers themselves saying QML is still insufficient to completely repace widgets for desktop apps. Also, if this market you claim was growing so fast then there would be no point to closing the office since clearly someone would have been begging to buy it. Also, i loled about your Digia statement despite the fact that more people are still buying new commercial licenses every day and more new software is being made that uses QWidgets.
17. Re:For better or for worse... by Desler · 2012-08-01 03:53 · Score: 2
  
  And high quality software does handle errors. You seem to be wrongfully blaming deficiencies in Qt's implementation on the langauge. 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. Eitherway, I've used tons of crappy Java and .Net applications that have failed to catch exceptions or check errors and routinely crash because of this. As the person above said, you seem to be just another boring, ignorant C++ hater. You might want to update your C++ hater points beyond what you read on yosefk.com or other lame whiner sites.
18. Re:For better or for worse... by arendjr · 2012-08-01 04:14 · Score: 4, Interesting
  
  Like it or not, thanks to Windows 8 "real desktop application" and "Metro app" will increasingly mean the same thing in the future. QML is a result of Nokia's (failed) mobile efforts, but thanks to it, Qt (unlike pretty much any other toolkit) is actually able to create competitive interfaces, regardless of whether the competition is using traditional widget-based interfaces or Metro-style interfaces.
  So yeah, I agree with GP here, QML is the best thing to happen to Qt in a long time.
19. Re:For better or for worse... by X0563511 · 2012-08-01 04:17 · Score: 1
  
  Why? It's not like the code is just going to evaporate if nobody picks it up.
  
  --
  For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
20. Re:For better or for worse... by Anonymous Coward · 2012-08-01 04:36 · Score: 0
  
  I've been programming longer than some of you have been alive. And my experience has taught me that you never through an exception you yourself aren't prepared to catch. By "you" I mean both you personally and not your coworker down the hall, and you as the module you're coding (ideally not even the compilation unit). You don't just throw them over the wall hoping someone else will catch them. All exceptions will crash a program if not handled. All are fatal. This should go without saying, yet people continue to use them as if they were a general purpose error reporting system.
  This is why I greatly appreciate Qt's exception policy. Qt DOES use exceptions, but only internally. It just doesn't throw exceptions out to the end user developer.
21. Re:For better or for worse... by betterunixthanunix · 2012-08-01 04:37 · Score: 4, 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:
  
  try { } finally { throw new SomeException(); }
  
  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?
  
  --
  Palm trees and 8
22. Re:For better or for worse... by MightyYar · 2012-08-01 04:39 · Score: 1
  
  Windows, Mac, and the various unix-like desktops are all moving targets.
  
  --
  W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
23. Re:For better or for worse... by betterunixthanunix · 2012-08-01 04:40 · Score: 1
  
  And my experience has taught me that you never through an exception you yourself aren't prepared to catch.
  
  That's fine if you have a good way to signal errors to client code. Error codes and return values are lacking in that department, because client code can (and probably will) ignore them.
  
  --
  Palm trees and 8
24. Re:For better or for worse... by Anonymous Coward · 2012-08-01 05:05 · Score: 0
  
  Nope. Pretty much all core Qt developers have drunk the QML KoolAid(tm). It's pretty sad. I'm hoping the Elop-itis they all contracted will wear off after a while, and we can get back to reality.
  Claim: widgets are too slow for modern interfaces. Huh, a class that handles user events and draws to a rectangular regular is too slow? Then fix the widgets! There is a lot of cruft in QWidget, but that WAS getting taken care of until Elop and Knoll decided they could speed things up by dumping C++ for JSON.
  Claim: The sequential rendering pipeline of QPainter is too slow. Yeah? So what? Maybe it's too slow if I have several hundred animated doodads flowing over the screen, but don't tell me that using a standard QPushButton is slowing down the application! There are areas to improve painting but that's a reason to fix QPainter, not to officially deprecated it in favor of a new scene graph that doesn't even have C++ bindings! There is also the related claim that QGraphicsView is too slow because of sequential painting, so they replaced it with a Javascript-only scene graph. But the big bottleneck of QGraphicsView was its poor indexing, something that QtQuick 2 did not address. Besides, there was nothing stopping QGraphicsView from drawing its items in parallel. Nothing but politics.
25. Re:For better or for worse... by rdnetto · 2012-08-01 05:10 · Score: 1
  
  You joke, but there's already a lightweight Qt-based desktop environment called Razor-QT that runs quite nicely on the RasPi, though it is still a bit rough around the edges since it's still in development.
  If all else fails, the KDE project could probably assimilate it.
  
  --
  Most human behaviour can be explained in terms of identity.
26. Re:For better or for worse... by Jurily · 2012-08-01 05:12 · Score: 1
  
  I worried about Qt's future when they tried forcing Qt onto Symbian. I'm glad they gave up. If all else fails, we can still have a Free port maintained by the KDE people or something.
27. Re:For better or for worse... by tibit · 2012-08-01 05:22 · Score: 4, Informative
  
  They could have made widgets hardware accelerated and easily animated.
  Yes. And that's how QML came to be, because when you actually try to make "widgets" do all that you end up with something that's not widgets anymore. Do you seriously believe that the mindset was "let's come up with something new from scratch, we've got too little work to do"? The legacy widget model has insurmountable performance issues that cannot be overcome in that model. If you don't understand that, you need to do some research first, perhaps actually try coding something up and convincing everyone how your supercool painter widget based model keeps up with competition.
  There's no way to get good performance from a painter-based architecture that asks everyone to repaint their part when something changes. This model made sense for a while because common graphics hardware was generally slow and had no acceleration to speak of when it comes to graph-based representations of the visuals. It doesn't make any sense anymore. When a window moves and is to be recomposited, you shouldn't have to transfer more than a command or two to the graphics card to change a couple coordinates. It'll be picked up next time the rendering is done. In the painter-based model, at best you have backbuffers for every window (even if a window has a flat background that can be represented by two flat shaded triangles -- two dozen numbers at the most, not a megabyte), and those backbuffers have to be composited.
  The widget model not only sucks performance-wise, but it also sucks resource wise: you need a lot more memory and a lot more memory bandwidth to render even fairly simple things.
  
  --
  A successful API design takes a mixture of software design and pedagogy.
28. Re:For better or for worse... by X0563511 · 2012-08-01 05:24 · Score: 2
  
  That hasn't stopped GTK+ from working on all three platforms. Why would QT be any different?
  
  --
  For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
29. Re:For better or for worse... by Anonymous Coward · 2012-08-01 05:25 · Score: 1
  
  If you rewrote QWidgets in a light weight framework like QGraphicsView or a scene graph, at least it would be C++ instead of a web developers language!!! At least you would have C++ bindings for the scene graph, instead of nothing at all! At least you would still have widgets instead of having to reinvent the push button for every project!!!
  QML is the result of a political decision by Stephen Elop and Lars Knoll. Widgets bad, get rid of them. C++ bad, get rid of it. Desktop bad, everything is now 100% focused on mobile. WE STILL DON'T HAVE DESKTOP COMPONENTS YET! They will not be in the release of Qt 5.0, and probably not even in 5.1.
  QML was a good idea, is a good idea. I have no problem defining the UI with a descriptive language of some sorts. But the idea that C++ must be confined to the back end business logic is fucking stupid. Is Nokida afraid the sight of some C++ will scare away the precious snowflake web developers that they think are Qt's target market?
30. Re:For better or for worse... by tibit · 2012-08-01 05:25 · Score: 2
  
  Huh, a class that handles user events and draws to a rectangular regular is too slow?
  Yes. Because when the graphics card does the actual rendering using the modern 3D hardware, you don't need the rectangular window anymore, nor its memory and bandwidth baggage. If you actually understood how it works, and what it takes to composite legacy rectangular widgets, you'd have understood it. As it is, you're talking out of your ass, demonstrably without any technical understanding of what's involved. Sorry.
  
  There are areas to improve painting but that's a reason to fix QPainter.
  It's got nothing to do with fixing QPainter, you're delusional if you think so. The model where something changes on the display and user code is asked to do repaints is crazy when you have a piece of very fast graphics hardware that will do all that for you without a single line of code running on the CPU, without a single task switch even though there may be windows from a dozen applications all being updated.
  
  --
  A successful API design takes a mixture of software design and pedagogy.
31. Re:For better or for worse... by Anonymous Coward · 2012-08-01 05:28 · Score: 0
  
  So is that why C++ was dumped in favor of Javascript? Because Javascript is faster?
32. Re:For better or for worse... by gbjbaanb · 2012-08-01 05:40 · Score: 1
  
  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
  I don't understand this - of course you have to prevent some exceptions from propagating - ie catching them. If you don't catch them anywhere, they end up in the default handler which usually stops your program by design.
  Exceptions are seen as magic error handlers by some people, but the truism that you should never throw an exception you're not prepared to catch is valid. Similarly, you could say you should never return an error code if you're not prepared to check it. The only difference is really in that checking code - the exception handler can be placed in a different location to the error handler code, which can often help code readability. That's all there is to it though, if you ignore an error code - fine you know the call may not have worked. If you ignore an exception - fine, you know your program may stop.
  So how to make exceptions opt-out rather than opt-in... the only way is to inspect all the exceptions a piece of code will throw (and the code it uses itself) and then create handlers for each of them, or just wrap all function calls with a generic catch(...) handler which will at least provide a quick and easy way to catch all those exceptions, unless you handle them first. So the best practice is really to write the equivalent of a switch's 'default' case every time.
33. Re:For better or for worse... by Anonymous Coward · 2012-08-01 05:44 · Score: 0
  
  I didn't say you could keep QWidget/QPainter unchanged! There are several obvious fixes that don't require the use of JSON or Javacript to implement.
  For example, paint to a OpenGL texture instead of to the screen. Then you can paint all of your widgets / graphics items in parallel. You would still need a dirty bit, because in real life stuff does change and its appearance does need to be updated. But now because we are painting to a texture, we can do this outside of the paint event and in a different thread.
  And by using the word "rectangle" I did not imply a fixed and bounded region. QGraphicsView items certainly are not limited to externally imposed boundary. Sorry if my use of the word got your panties in a wad.
34. Re:For better or for worse... by gbjbaanb · 2012-08-01 05:55 · Score: 2
  
  So is that why C++ was dumped in favor of Javascript? Because Javascript is faster?
  It wasn't, you're confusing a few things. Javascript is used as the glue that ties a few events and methods together, but you still pass them down to your c++ program logic to do work. If you just need to change a radio button when another one is pressed, then that hardly needs and c++ logic, a little bit of js would be quite sufficient and make no noticeable difference to performance.
35. Re:For better or for worse... by Anonymous Coward · 2012-08-01 06:03 · Score: 0
  
  So? Client code that will ignore my error code is client code that won't catch my exception. The difference is that not all of my errors are fatal, whereas by definition every exception is.
  Example, parsing a numeric string. If I cannot convert the string to an integer, I could set the value to 0 and return/set an error code. If the error code is ignored, the program will not crash. But if I did it in the "purist" way I would throw and exception instead. Now the program crashes.
  You SHOULD check for all return codes, and you SHOULD handle all exceptions. But we're talking real life here, not the idealized world they taught us in college. In real life error codes sometimes don't get checked and exceptions sometimes don't get handled. The solution is to, as best as is possible, deal with the error at the point that it occurs, instead of handing it off to someone else with less knowledge to deal with.
  Not all unhandled errors should be fatal, but by using exceptions you do make them fatal.
36. Re:For better or for worse... by HiThere · 2012-08-01 06:41 · Score: 2
  
  You just started worrying? I started back when Trolltech was acquired. This only got worse when MS "acquired" Nokia. (And yes, I *do* know that officially that hasn't happened.) I will be quite worried about who they will find to sell it to. This is the more significant with the Gnome folk trashing their own libraries. It's enough to cause one to suspect outside influences.
  
  --
  
  I think we've pushed this "anyone can grow up to be president" thing too far.
37. Re:For better or for worse... by CadentOrange · 2012-08-01 06:47 · Score: 4, 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 ...
38. Re:For better or for worse... by ardor · 2012-08-01 07:28 · Score: 1
  
  This is an imperfect solution which assumes that redrawing inside the window (which is the OpenGL texture) is done quickly enough. It also splits the system into two parts: the hardware-accelerated window compositing part and the unaccelerated drawing part.
  More sophisticated solutions exist. Examples:
  Using distance fields in OpenGL shaders for font rendering
  Using textures for anti-aliased vector graphics rendering
  Spline rendering in the GPU for non-affine vector graphics rendering (including text)
  Such techniques assume the presence of a GPU. Forget about abstracting that away with a painter-based architecture. The fundamental problem is that the painter acts at a level that is too low. This is the reason for the higher-level QML scenegraph. As for the missing C++ bindings, thats debatable, but if some appear one day, expect a high level API. Nothing else makes sense.
  It should be noted that the Enlightenment Foundation Libraries do something very similar with the combination of Evas and Edje.
  
  --
  This sig does not contain any SCO code.
39. Re:For better or for worse... by davydagger · 2012-08-01 07:28 · Score: 1
  
  my ass it is.
  
  GTK is far better, or at least doesn't crash X with nvidia drivers
40. Re:For better or for worse... by X0563511 · 2012-08-01 07:29 · Score: 1
  
  Never had a problem with GTK apps on windows or mac. Just make sure you've got the proper theme installed into the run-time environment and if necessary tell GTK to use it.
  Here's some proof if you don't believe me. Looks totally correct, and GIMP looks the same, too.
  While it should just work, for other reasons I've got "gtk+-bundle_2.24.10-20120208_win32" installed, set it's \bin to my %PATH%, and even went so far as to symlink \gtk to it. This is all done because I've got several versions laying around and wanted to be sure it was using the right one.
  
  --
  For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
41. Re:For better or for worse... by luis_a_espinal · 2012-08-01 07:39 · Score: 1
  
  Having a great toolkit that makes highly efficient applications and is source compatible on tons of operating systems? Where is the problem exactly? Oh, you must be one of those Java 'programmers'.
  Because generalizations are the stuff smart people use to sound smarter or more technically proficient </roll-eyes>
42. Re:For better or for worse... by betterunixthanunix · 2012-08-01 07:49 · Score: 1
  I don't understand this - of course you have to prevent some exceptions from propagating - ie catching them.
  That is not what I mean; what I mean are things like destructor exceptions e.g. closing a file can result in an error condition, and exceptions are basically the only reliable mechanism to signal that. In C++, iostream classes have that exact issue, and the standard dictates precisely what I said: if closing a file causes an exception to be raised, the destructor must catch it and do nothing, which is another way to say that the error will happen silently. There was, I am told, a very lengthy debate about this on Usenet and in committee meetings, because some people wanted a Lisp-style restarts system (or no change from C++98), but the committee went a different way on this issue.
  
  Similarly, you could say you should never return an error code if you're not prepared to check it
  There are two non-cosmetic differences:
  
  There is no way to guarantee that a C++ program will check an error code, nor does the language actually require such a thing. The best we have are separate tools that allow us to assert and prove that error codes are being checked, which can be used by programmers who want to do such things. With exceptions you are at least guaranteed a runtime error if the exception is not handled.
  There are some situations where an error code would not even be feasible. When a function is called, objects are copied; the copy constructor may have an error, but there is no sequence point between the copy constructor calls. You would need a very complex system for registering the error codes, and in C++ this is even worse because the order of copy constructor calls is undefined. This is the real selling point of exceptions: you can signal an error even in places where functions are not explicitly called.
  Really, in a language like C++, exceptions are the only good way to signal errors; that is why getting exceptions right is critical to enabling programmers to write reliable code, and why getting exceptions wrong (which I contend is what happened in C++11) makes writing reliable code far more difficult.
  
  So how to make exceptions opt-out rather than opt-in... the only way is to inspect all the exceptions a piece of code will throw (and the code it uses itself) and then create handlers for each of them, or just wrap all function calls with a generic catch(...) handler which will at least provide a quick and easy way to catch all those exceptions, unless you handle them first. So the best practice is really to write the equivalent of a switch's 'default' case every time.
  Yes, and there is a top level catch-all that will terminate the program in any language that has exceptions. That is a fine thing to do, but consider the difference in Common Lisp (at least those implementations I have used): the top level catch-all presents the user with options that are specified by the function which throws the exception. Thus a failed attempt to close a file might give the user a "try again" option, which the user can use after freeing disk space. Clearly such a thing will not always work: the program might be non-interactive, but you can always override this behavior with your own top level catch-all.
  
  As a final thought, the C++ goal of being both high- and low-level has questionable merit. High level programming is only about program logic; low level programming involves some logic, but must also deal with mechanics. Most of the code that is in use today is high level i.e. there is nothing machine-specific about it, it was written to implement a particular abstract algorithm or process. This is true of C++ code as well: most C++ code is high level code. Unfortunately, in order to satisfy the needs of low level programmers, C++ does not provide certain high level features (garbage collection being the most prominent, but also multiple dispatch
  --
  Palm trees and 8
43. Re:For better or for worse... by ardor · 2012-08-01 08:08 · Score: 4, Informative
  
  I wish to elaborate on why the painter model is inefficient with today's GPUs.
  The painter employs an imperative approach that does not allow for much freedom. Example: begin(), line(), text(), line(), end(). The two line() calls should be grouped together, but they cannot, because then the result would not be equal (what if text() drew over the first line, then the second line() call drew over the text for example?). The result is pretty bad: the underlying implementation has to perform tons of unnecessary shader switches (since font rendering most likely uses different shaders than the line drawing code), and perhaps texture switches (if texture-based AA is used). In addition, every time the painter is used, a vertex buffer has to be filled with vertex data. It cannot be easily cached. And this applies to *every* begin..end painter sequence.
  A declarative QML-like approach is a much, much better idea. The fundamental reasons are that (1) the renderer now always has a global picture of what the frame shall look like, (2) intermediate results are much easier to cache, (3) no strict sequence of drawings is given, therefore the renderer is free to reorder and merge drawcalls in any way it wishes. This benefits even pure CPU-based rendering - the Enlightenment Foundation Libraries render using a graph, and are extremely efficient (they clip and cull primitives early on, group primitives together, IIRC can even detect accumulated opacity from several alpha blended layers ..).
  C++ QML bindings would likely consist of an API that can modify the graph. Either way, the painter-based approach is gone.
  
  --
  This sig does not contain any SCO code.
44. Re:For better or for worse... by Stele · 2012-08-01 08:20 · Score: 1
  
  We get it - you don't like C++.
  Personally, I have several Qt/C++ applications on the market that pretty much anyone (except maybe you) would consider "high quality". I'm certainly very satisfied with Qt.
45. Re:For better or for worse... by betterunixthanunix · 2012-08-01 08:22 · Score: 1
  
  Client code that will ignore my error code is client code that won't catch my exception
  Except that the behavior of a program following an unhandled error is essentially undefined -- the only well-defined behavior is to terminate. That's what exceptions give you; if the programmer does not define how an error should be handled, the program just stops. In terms of a state machine model, if the program enters an error state and has no transitions out of that state, it halts.
  
  The difference is that not all of my errors are fatal, whereas by definition every exception is.
  No, not all exceptions are fatal, at least not in languages that support restarts or continuations. You can have exceptions that are recoverable or ignorable; the programmer just needs to specify that that is what should happen.
  
  Example, parsing a numeric string. If I cannot convert the string to an integer, I could set the value to 0 and return/set an error code. If the error code is ignored, the program will not crash.
  Unless you try to divide by the integer you converted to, in which case you crash, and you lose the information about why you crashed. This can be even worse: you might have been trying to read the price of an item, but a thumb drive was removed, and now the price is set to zero -- which is not what you wanted. Unhandled errors are bad things and should be discouraged.
  
  we're talking real life here, not the idealized world they taught us in college
  In real life, unhandled errors cause worse problems than program crashes:
  
  http://descriptions.securescout.com/tc/16657
  
  The solution is to, as best as is possible, deal with the error at the point that it occurs, instead of handing it off to someone else with less knowledge to deal with.
  Sure, but sometimes you really have no other choice. If the disk is full, you can possibly correct the error by asking the user to remove some files; but if you are not interactive, then you cannot do so. Exceptions with restarts are the answer; not error codes, and certainly not allowing client code to just ignore error states.
  
  --
  Palm trees and 8
46. Re:For better or for worse... by betterunixthanunix · 2012-08-01 08:26 · Score: 1
  
  OK, and I did not say it is impossible to do that -- just that it is needlessly difficult, and that as a result it is unusual. People have also written high quality software in assembly language, but if you needed to write high quality software, I doubt that assembly language would be your first choice.
  
  --
  Palm trees and 8
47. Re:For better or for worse... by luis_a_espinal · 2012-08-01 08:32 · Score: 1
  
  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
  I don't understand this - of course you have to prevent some exceptions from propagating - ie catching them. If you don't catch them anywhere, they end up in the default handler which usually stops your program by design.
  I think he's referring to the poor exception semantics in C++, in particular that there is no exception "top" type. If that's not what he means, at least that is something I've had to face with when it comes to developing C++. As you know, a throw can take on anything, even an int. There is no exception type as a first class type, and as result, there is no "top" type for them.
  But since anything can, in theory, be thrown at your code, your code must always have a catch(...) as the last catch of every try you have (if you want to print some time of line-code diagnostics, which is all you'll ever had)... or at the very least a catch(...) at the top-most section of your program/event loop.
  Since you cannot determine anything at all from whatever that falls into a catch(...) block, you are restricted to do a "unknown error" handling operation, or to silently ignore it. Either way, that is a type of errors that you cannot effectively handle (note the wording, "effectively handle"). Logging a "something happened" error message (or ignoring an unknowable exception) to prevent a crash is essentially not handling the error to avoid the crash (because there is no way to effectively handle something that cannot be diagnosed.)
  And that is the main semantic problem with C++ exception handling (on top of many others). C++ exception handling makes Java checked exceptions look incredibly appealing (and that is no compliment.) It is not only Qt that opts for error codes over C++ exceptions. A large number of very important systems (.ie. Azul's VM for example, or many C++ system in the defense sector) follow similar design decisions.
  
  Exceptions are seen as magic error handlers by some people, but the truism that you should never throw an exception you're not prepared to catch is valid.
  
  Another truism is to never assume the thrower of an exception is either you or some other entity under your direct control. In any sufficiently large/complex system, your code will be used by others, or will be layered over others' code base, or will interface with other component. In such situations, a exception mechanism without a "top" exception super type can quickly become more a liability than anything else. That uncertainty makes error codes a better alternative. Mind you that this is only true in C++ (but false in all other languages with true "top" exception types.) Similarly, you could say you should never return an error code if you're not prepared to check it. The only difference is really in that checking code - the exception handler can be placed in a different location to the error handler code, which can often help code readability. That's all there is to it though, if you ignore an error code - fine you know the call may not have worked. If you ignore an exception - fine, you know your program may stop.
  So how to make exceptions opt-out rather than opt-in... the only way is to inspect all the exceptions a piece of code will throw (and the code it uses itself) and then create handlers for each of them, or just wrap all function calls with a generic catch(...) handler which will at least provide a quick and easy way to catch all those exceptions, unless you handle them first. So the best practice is really to write the equivalent of a switch's 'default' case every time.
  As a said, an exception system that permits generic catch(...) blocks but does not provide a "top" exception super type is a system that makes effective universal exception handling impossible.
48. Re:For better or for worse... by gbjbaanb · 2012-08-01 09:52 · Score: 1
  
  I understand, and it does seem that a hierarchy of well-defined exceptions would be something the standard body could consider, but you'd still be stuck with backwards-compatiblity with throwing an int.
  I guess you could attempt to build your own, rely on exceptions derived from std::exception, and then use a global handler to catch all other exceptions.
  I'm a pragmatic chap, I know there is no perfect code, and that you can't build it in other languages that do have well-defined exception hierarchies (eg in .NET a StackOverflow exception cannot be caught and will stop your program, *without* reporting any error. Nice).
  In most C++ apps, an exception is a way of specifying something terrible has happened that cannot often be handled except to log and halt. What you see in languages that have an exception top class is exceptions used for all kinds of program flow. Perhaps its a good thing C++ doesn't have such a construct given this.
49. Re:For better or for worse... by gbjbaanb · 2012-08-01 09:59 · Score: 1
  
  I agree with a fair bit of that, but you need to get up to speed on modern C++. Try this video, it's not too long but is very good for you.
50. Re:For better or for worse... by shutdown+-p+now · 2012-08-01 10:00 · Score: 3, Informative
  
  QML is a result of Nokia's (failed) mobile efforts, but thanks to it, Qt (unlike pretty much any other toolkit) is actually able to create competitive interfaces, regardless of whether the competition is using traditional widget-based interfaces or Metro-style interfaces.
  It's not the only toolkit - WPF is quite similar, and shares many of the same concepts. Qt is the only such C++ / native code toolkit, though, and it's a fair bit faster than WPF. And portable to boot.
51. Re:For better or for worse... by shutdown+-p+now · 2012-08-01 10:02 · Score: 4, Insightful
  
  The real awesomeness about QML is not the visual graph - for a high-level UI developer that's an implementation detail. What makes it awesome is declarative UI markup, and flexible data bindings to the model. It's what MVC should have been from day 1.
52. Re:For better or for worse... by shutdown+-p+now · 2012-08-01 10:03 · Score: 2
  
  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).
  That's not true - destructors default to noexcept(true) in C++11, but you can explicitly override that.
53. Re:For better or for worse... by Anonymous Coward · 2012-08-01 10:06 · Score: 0
  
  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:
  Hmmh? Stack information is retrievable from the exception object itself, it is not lost (which also makes Throwables rather expensive to construct). But I fail to see why ability to catch and drop Exceptions is somehow bad thing for a language. You are certainly free to let exceptions percolate as high as you want to... which is, after all, the default unless you explicitly catch them.
54. Re:For better or for worse... by Anonymous Coward · 2012-08-01 10:09 · Score: 0
  
  If all else fails, the KDE project could probably assimilate it.
  Not only can they, its in their charter.
55. Re:For better or for worse... by Anonymous Coward · 2012-08-01 10:11 · Score: 0
  
  Yeah, GTK on Windows is about as 'fake native' as a Java application, until you try to save a file and you get this shitass Linux dialog in your face instead of the standard file dialog.
56. Re:For better or for worse... by X0563511 · 2012-08-01 10:20 · Score: 1
  
  True, it's not the standard file chooser, but it's not "shitass" any more than the normal Windows one is. It's functionally identical.
  
  --
  For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
57. Re:For better or for worse... by ardor · 2012-08-01 10:23 · Score: 1
  
  That is another benefit, you are right. Don't underestimate the huge advantage it brings to the rendering engine, however.
  Anyway, I guess we can agree that QML is a good idea overall :)
  
  --
  This sig does not contain any SCO code.
58. Re:For better or for worse... by shutdown+-p+now · 2012-08-01 10:29 · Score: 1
  
  I can certainly understand the advantages to graphics developers. I'm just looking at it from my own angle, which is more about placing buttons together.
  And yes, it's certainly a good idea overall. I was hoping that someone would do something like that ever since WPF came out and showed what's possible there (for all its perf flaws and XAML verbosity). QML takes the same ideas and pushes them even further. I only wish they had full-fledged widgets available there from day 1.
59. Re:For better or for worse... by Anonymous Coward · 2012-08-01 10:32 · Score: 0
  
  Nothing is more aggravating than having a library throw an unexpected exception. Returning an error code is self documenting and obvious. No C++ compiler will detect unhandled exceptions, so it is easy to miss. I understand Java has more advanced exception features, however, even with all that nearly every Java program I've seen is highly unstable.
60. Re:For better or for worse... by Anonymous Coward · 2012-08-01 11:02 · Score: 0
  
  GTK+ apps look out of place on Windows, even more so on Mac.
  Qt apps don't integrate well on the mac either. You can spot them a mile away.
61. Re:For better or for worse... by Anonymous Coward · 2012-08-01 11:56 · Score: 0
  
  I worked for a company that made one of the few embedded Qtopia phones(Garmin). I can tell you for certain, QT is going no where on Embedded.
62. Re:For better or for worse... by spitzak · 2012-08-01 13:19 · Score: 1
  
  You do know you can use hardware acceleration to draw into an OpenGL texture, right?
  I am a bit confused as to what you are arguing for. I agree that Qt widgets are vastly overweight, and a redesign that makes it practical to have many orders of magnitude more widgets representing much simpler objects such as lines would be more efficient and powerful, and this is what the newer designs are attempting. But it has nothing to do with moving the drawing to hardware acceleration.
63. Re:For better or for worse... by spitzak · 2012-08-01 13:32 · Score: 1
  
  We have had very good results with assuming that std::exception is the "top" as he calls it.
  The non-std::exceptions are limited and in fact indicate cases where we *must* catch it, or where they should not occur except inside a catch. One is boost::thread_interrupted, which should only be thrown inside a boost thread and thus inside a catch for it. Another is a special exception we have for a "cancelled" dialog box, which must be caught so that the user cancelling a dialog box does not pop up an error-reporting dialog.
  This is nowhere near as bad as the initial poster makes out.
  I can imagine problems if arbitrary 3rd-party libraries are used, but even then we are seeing std::exception used.
  Having made a cross-platform toolkit I believe the blame for Qt's bad handling of exceptions is due to the WIN32 api. It is impossible (at least with earlier C++) to propagate an exception from an event handler back to the code that called "wait_for_event()". This is trivial in the X api, and not really difficult with OSX. My toolkit (FLTK) "fixed" this by translating all exceptions in WIN32 into the same "an exception was thrown" exception, which is hardly a fix because it is incompatible with the X version. I can't blame Qt for just saying that exceptions should not be used.
64. Re:For better or for worse... by spitzak · 2012-08-01 13:34 · Score: 1
  
  You may be right about it being a good idea for Qt itself to not throw exceptions.
  However what programmers (at least me) want is to be able to throw exceptions in message handlers and have them caught by the code that sent the message. It is not Qt throwing them, I just want them to pass cleanly through.
65. Re:For better or for worse... by tibit · 2012-08-01 16:23 · Score: 1
  
  If all applications were about placing buttons together, you'd be right. But then people ask "ah, well, how hard it may be to have translucent windows/non-rectangular windows". And then they say "well, now I'd like this one widget to be translucent, see". And boom. The painter-based model falls apart. Even if nothing is translucent, using hardware-accelerated rendering is only effective when using a non-painter rendering model.
  
  --
  A successful API design takes a mixture of software design and pedagogy.
66. Re:For better or for worse... by Argon · 2012-08-01 16:48 · Score: 1
  
  I wish I had mod points, not that it would've made a difference since you're already at score 5. You made my day :-).
67. Re:For better or for worse... by shutdown+-p+now · 2012-08-01 17:10 · Score: 1
  
  Well, again, from the angle of the guy who places buttons together, all I care about is having a two-line way of saying "now make this translucent please". Then of course I'll also want various composable render transforms, preferably complete with declarative time- and event-driven animations, and so on. The precise graphics model that backs this is, again, an implementation detail from that perspective - one only cares that the features it enables are all there.
  (note that I'm not arguing for the painter model here, so I'm not sure what you mean when you say "you'd be right" - did you confuse me with the "shove out new crap" OP to whom you replied earlier?)
68. Re:For better or for worse... by Anonymous Coward · 2012-08-01 18:30 · Score: 0
  
  The QGraphicsView engine is garbage slow on most embedded devices... getting performance out of QGraphicsView is... non-trivial. Yes the N9's use of QML is Qt Quick 1.0 which is QGraphicsView, but in order to get reasonable performance from it, it requires incredible restraint and planning. The punchline reason is that QGraphicsView uses QPainter to draw which is a slow piece of junk (be it GL1, GL2 or raster based QPainter.. all are junk slow). You can witness that QPainter is garbage slow as it is quasi-deprecated in Qt5.. but in all honesty they are in for a world of hurt since QtWebKit MUST use QPainter to get pixels to the screen.
  Qt Quick2.0 uses QtSceneGraph which is.. better.. but again, to get performance on embedded devices requires care and restraint. QSG has all sorts of design issues with regard to performance.
  Also think on this: Nokia owned TrollTech since 2008 and only made what, 2 phones using Maemo-Qt since then? The Symbian lead engineers often hate Qt as it leaked memory and is very slow.
  Not hard to imagine why they dumped Qt... no results. When people say Qt is the best C++ toolkit around, I know they are speaking from ignorance. Want drawing performance: use EFL. Want real C++ libraries with fast reliable implementations: use boost.
  Qt is at best a jack of multiple trades, but really, that is on it's best days... usually it is utter slow garbage. Open up the source read it, and go count the incredible number of WTF's.
69. Re:For better or for worse... by Anonymous Coward · 2012-08-01 18:54 · Score: 0
  
  What do you mean pipe dream? N9 uses Qt. As does all those Symbian phones like N8 and pureview.
70. Re:For better or for worse... by ardor · 2012-08-01 20:30 · Score: 1
  
  I explained this here: http://linux.slashdot.org/comments.pl?sid=3019601&cid=40847477
  Of course you can use framebuffer objects to draw into a texture. In fact, if I were to implement such a split solution (render textured quads with OpenGL for compositing the widgets, and use the CPU for drawing the widgets themselves), I would use FBOs. That still does not change the fact that drawing the widgets themselves remains unaccelerated.
  
  --
  This sig does not contain any SCO code.
Re:Correction to title: NOT Australian office by Anonymous Coward · 2012-08-01 02:58 · Score: 1

QuickTime Office? It's Qt not QT.
Do you do it for money or for love? by Anonymous Coward · 2012-08-01 03:00 · Score: 0

You can't have it bothways.
1. Re:Do you do it for money or for love? by DeathToBill · 2012-08-01 03:08 · Score: 4, Funny
  
  Unless you're Dominique Strauss-Kahn, of course.
  
  --
  Slashdot - News for Nerds, Stuff that Matters, in ISO-8859-1 Has just realised that beta makes this signature redundant
Re:Correction to title: NOT Australian office by Anonymous Coward · 2012-08-01 03:02 · Score: 1

Considering h111 cannot spell "source" correctly, I think it's asking an awful lot of him to get such a subtle capitalization detail correct.
Mod down by Anonymous Coward · 2012-08-01 03:07 · Score: 0

"Open sores", much like "M$", is an insult not likely to be employed by anyone worth your respect.
On the upside, thanks for making it easy for us!
Still a great toolkit despite Nokia by zenyu · 2012-08-01 03:18 · 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.
1. Re:Still a great toolkit despite Nokia by jpstanle · 2012-08-01 03:41 · Score: 1
  
  You keep your unity interface the hell out of my QT!
  Seriously though, it would be nice to see someone with the resources and, more importantly, the commitment to continue to develop QT. It's too good to let it waste away...
2. Re:Still a great toolkit despite Nokia by Enderandrew · 2012-08-01 04:18 · Score: 3, Insightful
  
  I've wondered how long it would take to make a Unity (or Gnome 3) clone shell with Qt and Plasma. The advantage of Plasma is that you can easily swap shells on the fly and give users choice (though frankly I think the traditional KDE desktop is far more usable than Gnome 3 or Unity).
  However, if anyone should purchase Qt, it should be Google. They can guarantee it will stay GPL. And Google themselves need to learn a few things about cross-platform apps. Apps like Picasa, Google Earth, Chrome, etc. probably should have used Qt from the beginning.
  
  --
  http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
3. Re:Still a great toolkit despite Nokia by Eravnrekaree · 2012-08-01 05:35 · Score: 1
  
  After Unity, i dont think we want Canonical to touch it. Unity is the worst. UI. Ever.
  Maybe Novell or SuSE.
4. Re:Still a great toolkit despite Nokia by Gavagai80 · 2012-08-01 06:12 · Score: 1
  
  Picasa and Google Earth weren't created by google (just acquired later), so can't blame them for those decisions.
  
  --
  This space intentionally left blank
I hope Google gets Qt by goruka · 2012-08-01 03:24 · Score: 4, Insightful

And integrates it to Android, NaCL, ChromeOS, etc. It would make developing and porting large applications to their platforms much, much easier.
1. Re:I hope Google gets Qt by chrb · 2012-08-01 03:39 · Score: 5, Interesting
  
  There already is QT for NACL. It's a very interesting idea, you can deploy QT apps over Chrome instead of having to target a native desktop. If you build for x86 and ARM you've got a complete software stack for web-accessible native GUI apps that will run on any platform that Chrome runs on (which apparently will soon include Android).
2. Re:I hope Google gets Qt by thatbloke83 · 2012-08-01 05:05 · Score: 2
  
  There is already a community-run project to port Qt to Android. It's called necessitas, and today the Alpha 4 version was released for testing.
  I've dabbled a bit with it with previous versions, and it's in a very good state already :)
  See here: http://sourceforge.net/p/necessitas/home/necessitas/ (It seems the website isn't showing alpha 4 yet, but it was announced on the necessitas mailing today that it was available).
3. Re:I hope Google gets Qt by gbjbaanb · 2012-08-01 05:50 · Score: 1
  
  In a way I hope Microsoft buys it.
  no, wait!
  Firstly, MS would do well with it - there is a ton of old MFC code out there that will need to be updated to something jazzy, and with the MFC->Qt migration tools, all that old code could be made shiny and modern. This is especially important given MS's renewed interest in native development. Its also important given MSs current GUI technology WPF being a bit shit - using way too much resources and performing really badly, really so for anything using lots of fancy animation.
  For all MSs faults, they do good documentation and put a lot of effort into making their tools work - remember the monkey dance to prove that! They also have a lot of developers who would love to be allowed to use it in corporate MS-only no-OSS environments. Suddenly Qt would get a lot of push forward to a lot of computers and developers and MS would get a really good GUI system (at last).
  I doubt Google would put much effort into it, and might end up shelving it after a few years like a lot of their other projects. They might be interested in Wt though - that turns the Qt code into a web front end.
4. Re:I hope Google gets Qt by DarwinSurvivor · 2012-08-01 08:11 · Score: 1
  
  For all MSs faults, they do good documentation and put a lot of effort into making their tools work.
  Right, that's why MSDN still has no facility to filter a search by programming language (finding the "c" version of a call is damn near impossible since it also brings up c++, c# & objective-c) and hitting recompile a second time in Visual Studio will fix some bugs in your software.
  I say this as someone that did a fair bit of win32 programming in College (required, trust me it was NOT by choice!) and it was by FAR the buggiest piece of crap I have EVER worked with and I've done JavaScript on IE6!
5. Re:I hope Google gets Qt by gbjbaanb · 2012-08-01 09:12 · Score: 1
  
  actually the MSDN v4 help system was the dogs danglies, then v5 went all HTML and was ... acceptable. The new one is a lot more rubbish... however, I was referring to the quantity of the stuff, they do not skimp on writing the stuff - and besides I use Google to search through the online version nowadays, that works :)
  Ps. it used to bring up the Windows CE version first, every time.
6. Re:I hope Google gets Qt by Anonymous Coward · 2012-08-01 09:12 · Score: 0
  
  hitting recompile a second time in Visual Studio will fix some bugs in your software.
  I'd love to see a citation for this. I've got years' worth of Visual Studio use under my belt and have never run into this situation. Visual Studio may have its problems but this isn't one of them in my experience.
7. Re:I hope Google gets Qt by DarwinSurvivor · 2012-08-01 10:59 · Score: 1
  
  I don't have a published citation, but our entire CST class went by the motto (and I am NOT paraphrasing here!) "If at first you don't succeed, recompile!" This motto was ONLY ever said while working on win32 in VisualStudio.
  Just a little background: I'm not talking about little clocks and stuff, we were writing low-level networking and GUI stuff such as streaming radio client/server setups, RFID readers and other fairly complicated applications.
8. Re:I hope Google gets Qt by DarwinSurvivor · 2012-08-01 11:00 · Score: 1
  
  I use Google to search through the online version nowadays, that works.
  We did that as well, but the only way to make it work was by adding "-c++ -c# -objective-c" to EVERY search.
Re:Correction to title: NOT Australian office by Anonymous Coward · 2012-08-01 03:28 · Score: 0

"open sores guys"
Eeeeewwwwwww.
Don't want those guys working on any code I use. Gives new meaning to software virus and makes a trojan seem like a good idea.
Re:Correction to title: NOT Australian office by mcgrew · 2012-08-01 03:45 · Score: 1

it seems like open sores guys
Someone please moderate that comment as the flamebait it is.

--
Free Martian Whores!
Nokia -- why? by Sipper · 2012-08-01 03:52 · Score: 2

All I can do is express my confusion. Nokia purchased Qt presumably with the intent of using it on their phones. They put out a couple of very good phones such as the N900 that leveraged Debian and Qt. All of that seemed like they were on the right path. Debian users practically swear by the N900.
And then... they announce plans to switch to a non-existent Windows platform. What? That was a total reversal of course away from what was previously a direction of free and open source software. Somewhere in the company I'm betting the reasoning given has to do with a spreadsheet of expected costs of development between the Qt and Windows platforms, and my personal bets are on those numbers being wrong and thus the wrong decision being made.
What matters to me personally is that Qt support structure survives this intact, because it's a very important framework. Thankfully Qt is GPL software, so the existing code will survive no matter what.
1. Re:Nokia -- why? by jonwil · 2012-08-01 04:11 · Score: 4, 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.
2. Re:Nokia -- why? by gl4ss · 2012-08-01 04:13 · Score: 1
  
  Because of Elop. have you been hiding under a rock?
  the reason why they got the board to go with it is that they spent something along to the tune of billion++ dollars on being prepared to do "great things" with whatever tech was the jesus tech of the day - that was the real expenses problem(and the structure of that development was such that it leaked lots of money to companies outside of Nokia).
  what they should have done would have been to fire the people anyways and definitely not announce dropping the whole system before they had replacements already on the market.
  technically it's probably that it took way too long for them to port the core qt libs to such a shape on symbian that they were usable for actually building apps. thing is they seemingly had a huge army of developers(which were just burning cash).. and then just a small core that didn't move anywhere for a long time doing the porting and bitching about symbian quirks preventing them doing things instead of fixing those quirks. in a word there was a lack of urgency in the whole endeavor which is hardly surprising since there were people working on it who were just attached to the project from outside of nokia (the longer it took the more money the company which contracted the people got).
  add to that spreading the work between multiple teams on multiple continents.. you could ask, why the hell were these parts in development in australia especially since there's parts there for which proper implementation on the systems that interested nokia would have needed direct access to the guys doing core symbian? which is something that on several occasions colored symbian development: managers didn't seem to understand that you can't fix problems in a bottom layer by building another set of api's on top of it that just map to the old one's when the problem was that the old api's didn't do what they were supposed to at all or were implemented so that they only did a specific sub task of the whole array of things you were supposed to use them for.
  So.. probably the board got enough of that. however that still doesn't excuse them for letting Elop do his stupid talk.
  
  --
  world was created 5 seconds before this post as it is.
3. Re:Nokia -- why? by Viol8 · 2012-08-01 04:14 · Score: 1
  
  Probably in case of failure. If Nokia's handsets tank and the company goes into the red because no one wants a Windows phone - which seems to be the way things are going - then I suspect they hoped they could have a soft landing in the form of being bought out by Microsoft and saved from themselves. Whether this will happen or not - who knows. Though to me it looks like a case of from the frying pan into the deepest bowels of hell.
4. Re:Nokia -- why? by tuffy · 2012-08-01 04:45 · Score: 2
  
  Microsoft has already thrown Nokia under the bus once when they denied the Lumia an upgrade path to Windows 8. So rather than rescue this dying company (and all its debts) with a buyout, they'll just wait for Nokia to crash and burn before picking up the useful pieces at fire sale prices.
  
  --
  Ita erat quando hic adveni.
5. Re:Nokia -- why? by RoccamOccam · 2012-08-01 05:04 · Score: 5, Interesting
  
  This. For quite a while, I've had a sneaking suspicion that Nokia's acquisition of Qt is one of the principal reasons that Microsoft embarked on their torpedo-Nokia strategy.
6. Re:Nokia -- why? by PolygamousRanchKid+ · 2012-08-01 05:40 · Score: 5, Insightful
  
  ex(?)-Microsoftie
  
  Does anyone believe that Elop is not still working for Microsoft . . . ?
  
  --
  Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
7. Re:Nokia -- why? by Anonymous Coward · 2012-08-01 05:42 · Score: 0
  
  I found a recent picture of Stephen Elop. You can see one of the Nokia board members just to the right.
  Stephen Elop.jpg
8. Re:Nokia -- why? by Anonymous Coward · 2012-08-01 08:43 · Score: 1
  
  I do not understand why Microsoft Nokia is getting rid of Qt. One would think that their ability to control both GTK and Qt via Microsoft employees Miguel de Icaza and Stephen Elop would be a good thing.
9. Re:Nokia -- why? by shutdown+-p+now · 2012-08-01 10:05 · Score: 1
  
  How exactly do you control an open source project?
10. Re:Nokia -- why? by Trogre · 2012-08-01 11:43 · Score: 1
  
  The way they always do. Sit on it until it dies.
  
  --
  "Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
11. Re:Nokia -- why? by shutdown+-p+now · 2012-08-01 11:46 · Score: 1
  
  It doesn't really work with open source - if there's demand for it, it'll just be forked (to remind, Qt is LGPL). If there's no demand, it dies, but then nobody cares anyway.
12. Re:Nokia -- why? by dbIII · 2012-08-01 14:29 · Score: 1
  
  you could ask, why the hell were these parts in development in australia
  Three reasons, which date back to before Nokia bought Trolltech.
  The first is a key developer in Norway had come from Australia, then went back, initially to work alone, but built up a team over a decade. I got the impression that Norwegian developers loved to spend time at the Australian branch (not far from the Gold Coast) during the Norwegian winter, so I think the two branches got a lot of contact.
  The second is with people in Norway and Australia they did have some projects or problems that got focused attention for the full 24 hours (which is partly why they hired the developer from Australia in the first place - he patched a lot of open Qt code "overnight" by putting in a full day in a different time zone).
  The third is it's after the year 1995 and we don't have to put memos on bits of paper anymore, so email etc can be used and airfares are not that expensive when somebody really has to be there. I've met people who telecommute from the US east coast to Ireland and from Tasmania to the US east coast.
  
  I've never been part of Trolltech or Nokia so the above is just from talking to some Trolltech people many years before Nokia bought them. I wish them all the best and hope something turns up for them.
probably a good thing for Qt by Blob+Pet · 2012-08-01 03:52 · 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.

--
"...today consumers have been conditioned to think of beer when they see a bullfrog..."
1. Re:probably a good thing for Qt by Anonymous Coward · 2012-08-01 15:36 · Score: 0
  
  All those resources were diverted to Meltemi. But we all know that Meltemi never existed.
Trolltech patents... by turkeyfeathers · 2012-08-01 03:58 · Score: 3, Funny

What happens if a patent troll gets the Trolltech patents?
Leadership Change by mx+b · 2012-08-01 04:16 · Score: 2

When you read the history, it makes more sense.
Nokia bought Trolltech (the original Qt developers) in 2008. I vaguely remember the articles at the time saying the reason was indeed so that Nokia could develop new GUIs for their phones. The new CEO of Nokia, Stephen Elop, became so in late 2010. Not long afterward is when the announcements started about going toward the WP7, and one by one stopping the other phone OS projects. Guess where Elop worked before taking over Nokia? Microsoft.
It's a shame that Qt has been passed around when it is such a terrific framework. I am not much of a programmer by trade, but I am by hobby, and it has been a joy to use on my personal projects. That modern KDE is so streamlined and adaptable is a testament to its abilities, and Qt 5 sounds like it will be a big leap forward.
Thankfully it is GPL, but without work, it will stagnate. I am sure many would love to contribute to it, but it is not practical to continue develop on it as hobby. Redesigning modules and all takes lots of time, and when are you supposed to do all that around your other jobs that you need to make money? I hope some corporate sponsors pick it up in some form, if not outright buying the assets/company, then at least sponsoring some hackers to work full-time on the open source version. Maybe a few KDE-centered distros will help out (SUSE?), if not KDE itself?. I'd be happy to buy a copy of the next SUSE to support development of a good distro and continued development of Qt/KDE.
Did the check bounce? by John+Hasler · 2012-08-01 04:22 · Score: 2

Seems like selling itself to Nokia wasn't the best option for Trolltech after all.
Did the check bounce?

--
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Google can buy it, give it to Stroustrup by Anonymous Coward · 2012-08-01 04:27 · 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.
1. Re:Google can buy it, give it to Stroustrup by Eravnrekaree · 2012-08-01 06:00 · Score: 1
  
  Sounds good to me. The patents it would seem are the really important part. The source code is GPL, I already have downloaded a complete copy of Qt source code, I advise others to do so, for safekeeping.
Google by Anonymous Coward · 2012-08-01 04:43 · Score: 0

Google, we need you now! Buy it!
Jolla? by cdp0 · 2012-08-01 04:44 · Score: 2

Maybe Jolla will buy Qt? It may be useful to them considering their plans, but I have no idea what the price is and if they can afford it.
Re:Correction to title: NOT Australian office by flimflammer · 2012-08-01 05:16 · Score: 1

He wrote "open sores" intentionally.
Not flamebait guys by Weaselmancer · 2012-08-01 05:34 · Score: 0

I haven't used Qt so I can't speak to the comparison, but VCL is actually pretty awesome. I've always liked CBuilder. It was doing RAD well and correctly back when MS solution was to make the dlls in Visual C and the UI in Visual Basic. Remember that mess? I will always have a fond spot in my heart for CBuilder for being a better alternative.
So take VCL, and couple that with Project Jedi and you've got a great dev environment. Scores of smart widgets, panels, sliders, panes, etc. If there is anything that rich for Qt I'd really like to see it. Seriously - I would! Not being snarky. I'd love to see something that rich as open source. I keep hoping and praying that the Jedi guys will do a port that will work on Lazarus, but so far no luck.

--
Weaselmancer
rediculous.
Since we're talking about potential purchasers ... by Anonymous Coward · 2012-08-01 05:40 · Score: 1

... I note with interest that Thiago Maceira - a hard-core Troll and formerly Qt's product manager - jumped to Intel a while back and works in their Open Source Technology Centre. He is still very heavily involved in Qt development.
Re:Correction to title: NOT Australian office by Anonymous Coward · 2012-08-01 08:03 · Score: 0

whooosh.
eh? seriously? by Anonymous Coward · 2012-08-01 14:35 · Score: 0

Unless you try to divide by the integer you converted to
If you try to divide by a number without having ensured it isn't zero first, you don't deserve to call yourself a programmer.
What floors me is that instead of improving programming practices, the effort is to try and make the languages make up for the fact that idiots are trying to program. Some very large number of you "programmers" would never get past my company's front door, I'll tell you that right now.
slashdot and anonymity by Anonymous Coward · 2012-08-01 14:39 · Score: 0

so let me get this straight:
* if you read articles on slashdot anonymously, no-one knows
* if you submit articles to slashdot anonymously, you're an anonymous reader
* if you comment on articles on slashdot anonymously, you're an anonymous coward
Re:Since we're talking about potential purchasers by UngodAus · 2012-08-02 18:56 · Score: 1

@Thiago, you know you can talk in first person, right? :)