Forgot your password?
typodupeerror
Linux Business Open Source Linux

Nokia Closing Australian Office, Looking To Sell Qt Assets 125

Posted by Unknown Lamer
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.
This discussion has been archived. No new comments can be posted.

Nokia Closing Australian Office, Looking To Sell Qt Assets

Comments Filter:
  • by Kensai7 (1005287) on Wednesday August 01, 2012 @10:54AM (#40842475)

    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

    • by Desler (1608317) on Wednesday August 01, 2012 @10:59AM (#40842541)

      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.

      • by Anonymous Coward

        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.

        • by Desler (1608317)

          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.

          • by tibit (1762298) on Wednesday August 01, 2012 @01:22PM (#40844771)

            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.

            • by ardor (673957) on Wednesday August 01, 2012 @04:08PM (#40847477)

              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 [enlightenment.org] 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.

              • by shutdown -p now (807394) on Wednesday August 01, 2012 @06:02PM (#40848937) Journal

                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.

                • by ardor (673957)

                  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 :)

                  • 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.

                    • by tibit (1762298)

                      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.

                    • 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 m

    • by Anonymous Coward on Wednesday August 01, 2012 @11:18AM (#40842809)

      I hope the Raspberry people buy it.

      Then they can call it Qt Pi.

      • by killmenow (184444)
        fresh outta mod points but that was funny.
      • by rdnetto (955205)

        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.

      • by Argon (6783)

        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 :-).

    • by zenyu (248067) on Wednesday August 01, 2012 @11:18AM (#40842821)

      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.

      • by jpstanle (1604059)

        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...

        • by Enderandrew (866215) <enderandrew@gmai l . com> on Wednesday August 01, 2012 @12:18PM (#40843619) Homepage Journal

          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.

          • Picasa and Google Earth weren't created by google (just acquired later), so can't blame them for those decisions.
      • After Unity, i dont think we want Canonical to touch it. Unity is the worst. UI. Ever.

        Maybe Novell or SuSE.

    • my ass it is.

      GTK is far better, or at least doesn't crash X with nvidia drivers
  • by goruka (1721094) on Wednesday August 01, 2012 @11:24AM (#40842879)
    And integrates it to Android, NaCL, ChromeOS, etc. It would make developing and porting large applications to their platforms much, much easier.
    • by chrb (1083577) on Wednesday August 01, 2012 @11:39AM (#40843043)
      There already is QT for NACL [qt-project.org]. 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).
    • 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/ [sourceforge.net] (It seems the website isn't showing alpha 4 yet, but it was announced on the necessitas mailing today that it was available).

    • by gbjbaanb (229885)

      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 [wordpress.com] - using way too much resources and performing really badly, really so for anything using lots of fa

      • 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!

        • by gbjbaanb (229885)

          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.

          • 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.

  • by Sipper (462582) on Wednesday August 01, 2012 @11:52AM (#40843239)

    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.

    • Re:Nokia -- why? (Score:5, Interesting)

      by jonwil (467024) on Wednesday August 01, 2012 @12:11PM (#40843521)

      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.

    • by gl4ss (559668)

      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 wh

      • by dbIII (701233)

        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

    • by Viol8 (599362)

      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.

      • by tuffy (10202)

        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.

    • 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 h

  • by Blob Pet (86206) on Wednesday August 01, 2012 @11:52AM (#40843243) Homepage

    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.

  • by turkeyfeathers (843622) on Wednesday August 01, 2012 @11:58AM (#40843333)
    What happens if a patent troll gets the Trolltech patents?
  • by John Hasler (414242) on Wednesday August 01, 2012 @12:22PM (#40843677) Homepage

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

    Did the check bounce?

  • by Anonymous Coward

    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.

    • 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.

  • by cdp0 (1979036) on Wednesday August 01, 2012 @12:44PM (#40844055)

    Maybe Jolla [wikipedia.org] 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.

  • ... 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.

COBOL is for morons. -- E.W. Dijkstra

Working...