Slashdot Mirror

← Back to Stories (view on slashdot.org)

Nokia Closing Australian Office, Looking To Sell Qt Assets

Posted by Unknown on 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.

38 of 125 comments (clear)

  1. For better or for worse... by Kensai7 · · 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 · · 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 · · 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 DeathToBill · · 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
    4. Re:For better or for worse... by Anonymous Coward · · Score: 5, Funny

      I hope the Raspberry people buy it.

      Then they can call it Qt Pi.

    5. Re:For better or for worse... by Stele · · Score: 2

      -1 Ignorant

    6. Re:For better or for worse... by betterunixthanunix · · 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
    7. Re:For better or for worse... by glebovitz · · 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.

    8. Re:For better or for worse... by betterunixthanunix · · 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
    9. Re:For better or for worse... by Desler · · 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.

    10. Re:For better or for worse... by arendjr · · 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.

    11. Re:For better or for worse... by betterunixthanunix · · 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
    12. Re:For better or for worse... by tibit · · 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.
    13. Re:For better or for worse... by X0563511 · · 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...
    14. Re:For better or for worse... by tibit · · 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.
    15. Re:For better or for worse... by gbjbaanb · · 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.

    16. Re:For better or for worse... by HiThere · · 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.
    17. Re:For better or for worse... by CadentOrange · · 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 ...

    18. Re:For better or for worse... by ardor · · 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.
    19. Re:For better or for worse... by shutdown+-p+now · · 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.

    20. Re:For better or for worse... by shutdown+-p+now · · 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.

    21. Re:For better or for worse... by shutdown+-p+now · · 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.

  2. Re:Do you do it for money or for love? by DeathToBill · · 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
  3. Still a great toolkit despite Nokia by zenyu · · 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 Enderandrew · · 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.
  4. I hope Google gets Qt by goruka · · 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 · · 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 · · 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).

  5. Nokia -- why? by Sipper · · 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 · · 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 tuffy · · 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.

    3. Re:Nokia -- why? by RoccamOccam · · 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.

    4. Re:Nokia -- why? by PolygamousRanchKid+ · · 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!
  6. probably a good thing for Qt by Blob+Pet · · 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..."
  7. Trolltech patents... by turkeyfeathers · · Score: 3, Funny

    What happens if a patent troll gets the Trolltech patents?

  8. Leadership Change by mx+b · · 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.

  9. Did the check bounce? by John+Hasler · · 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.
  10. Jolla? by cdp0 · · 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.