Slashdot Mirror

← Back to Stories (view on slashdot.org)

Nokia Announces Qt 5 Plans

Posted by Soulskill on from the eggs-in-a-backup-basket dept.

aloniv writes "Since Nokia announced its switch to Windows Phone 7, people have been worried about the future of Qt. Well, it turns out Nokia is still going full steam ahead with Qt, having just announced their plans for Qt 5. Some major changes are afoot code- and functionality-wise, but the biggest change is that Qt 5 will be developed out in the open from day one (unlike Qt 4). There will be no distinction between a Nokia developer or third-party developer."

129 comments

  1. Dupe? by MrHanky · · Score: 0

    I could swear I read this on Monday.

  2. wtf by Anonymous Coward · · Score: 0

    You guys don't think this would have been a good idea to mention sooner!?

    1. Re:wtf by eplawless · · Score: 2, Insightful

      At this point, Nokia is just tossing stuff out there as they think of it. "Oh man, we pissed off a massive chunk of our developer base. How do we make them less furious at us? ...besides scrapping the Windows Phone thing, I mean."

    2. Re:wtf by somersault · · Score: 1

      No kidding. I tried out Qt for the first time just before the MS deal was mentioned, and subsequently haven't bothered with it. If they're switching to a more open development model that will help to ensure it continues even if Nokia are savaged by MS, and if it's ported to more platforms, then that's enough reason to continue using it.

      --
      which is totally what she said
    3. Re:wtf by EsbenMoseHansen · · Score: 1

      It's LGPL. It can be forked at any time.

      --
      Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
  3. translation.... by metalmaster · · Score: 5, Insightful

    "There will be no distinction between a Nokia developer or third-party developer." becomes "Develop it yourselves you lazy bastards, but dont forget to put our name on it too"

    1. Re:translation.... by Anonymous Coward · · Score: 5, Funny

      "There will be no distinction between a Nokia developer or third-party developer."

      Which will be a disapointment for any Nokia developers hoping to get paid.

    2. Re:translation.... by Chemisor · · Score: 1

      Isn't that basically the philosophy of open source?

    3. Re:translation.... by diegocg · · Score: 2

      Plans to make QT a real community project already existed before Stephen Elop was made CEO of Nokia. And I would be very happy to see 3rd parties developing big chunks of QT - that would mean it can survive without Nokia.

    4. Re:translation.... by suy · · Score: 3, Insightful

      "There will be no distinction between a Nokia developer or third-party developer." becomes "Develop it yourselves you lazy bastards, but dont forget to put our name on it too"

      Very wrong. Look at the list of maturity and status of Qt modules. Nokia still is ready to maintain a huge percentage of Qt. They simply deprecated stuff because they think that other alternatives are better (eg. ditch Phonon because there is QtMultimedia). The only piece that Nokia is not interested in maintaining and that the comunity is worried about, is QtSVG, because the alternative, the SVG support in Webkit, is considered too big/slow, or unsuitable for being LGPL only.

      This is Qt development frameworks (aka "old Trolltech") being honest in what they are interested about.

      Oh, and being even more open in how they develop (they already have public BTS and reports).

    5. Re:translation.... by Kynde · · Score: 2

      Plans to make QT a real community project already existed before Stephen Elop was made CEO of Nokia. And I would be very happy to see 3rd parties developing big chunks of QT - that would mean it can survive without Nokia.

      QT would have no problems without Nokia. It's the "with" part that people are worried about. And never so much as now that there's another bigger "with" involved.

      --
      1 Earth is warming, 2 It's us, 3 it's royally bad, 4 we need to take action NOW
    6. Re:translation.... by Anonymous Coward · · Score: 0

      No, the correct translation goes:

      "Umm... we have a bunch of products. We have NO FUCKING IDEA how all these products relate or compete. Nor do we have any clue who are our friends, or our enemies. We're going to screw our enemies and fuck our friends. Or should that be fuck our enemies? We're going to fuck your phones and... wait..."

    7. Re:translation.... by lsatenstein · · Score: 1

      So, though you don't use Nokia cell phones or devices, you want them out of the goodness of their heart to provide you with a multi-platform GUI interface software. Who are you anyway, and why do you criticize

      --
      Leslie Satenstein Montreal Quebec Canada
    8. Re:translation.... by metalmaster · · Score: 1

      I do own a nokia featurephone. My point is that no distinction between developers will most likely leave more work to the third-party yet nokia's name will be attached. I thought atleast that much was clear in what i said....

    9. Re:translation.... by lsatenstein · · Score: 1

      Hi, Let's see, Nokia developed QT, and did it up to QT4. Now they have invested many manhours, salaries, and big dollars. They feel that it is time to turn QT over to the community because it is very worthy and because the community has a wealth of ideas about improvements.. Would you say they invested over a million dollars$ I would say so. I just feel that one should appreciate companies making good offers, but one could criticize companies taking away functionality (like Sony did)

      --
      Leslie Satenstein Montreal Quebec Canada
  4. Ugh.... by Anonymous Coward · · Score: 0

    While the QWidget based classes are extremely important for existing applications, we are, over time, going to move to a model where all UIs are being done in QML.

    Ugh. No thanks. I don't want to have to write my UIs in some bastardized version of Javascript and all the associated speed issues. Guess I'll be staying with Qt4 instead.

    1. Re:Ugh.... by Elledan · · Score: 1

      I agree. I have looked at QML (I'm a part-time C++/Qt developer), and it looks to me like JS and CSS had a very unsightly baby. QML is also not nearly as efficient or compact as the C++-based widgets. The latter could use a bit of an overhaul to remove some redundancy, but that's another matter again.

      Seems like Qt5 will be more buzzword-compliant, though :(

      Anyone up for developing a Qt competitor? :D

      --
      Site & blog: http://www.mayaposch.com
    2. Re:Ugh.... by gbjbaanb · · Score: 1

      yes, but then you can intermix QML and traditional Qt forms together which is a seriously good thing as you keep the productivity gains for the 80% of common or boring old functionalty and get to work the last 20% in less-rpoductive but mroe functional QML.

      Unlike XAML where you have a choice of all or nothing.

    3. Re:Ugh.... by Anonymous Coward · · Score: 0

      I'd rather having nothing. I'm using Qt to write C++ code not to be a Javascript monkey. Looks like the Qt are trying to make themselves irrelevant with statements like:

      We should expect that over time all UIs will be written in QML. JavaScript will become a first class citizen within the Qt community and we should expect that a lot of application logic and even entire applications will be written in JavaScript instead of C++. The expectation is that many application developers will actually start out with QML and JavaScript and only implement functionality in C++ when required. For those specific use cases, the full power of the C++ APIs offered by Qt can be used to implement time critical and complex application functionality.

      Even crap like GTK+ would be preferable over this write it all in Javascript world that Qt people seem to think will happen.

    4. Re:Ugh.... by Entrope · · Score: 5, Interesting

      I came from a Gtk+ background, but am using Qt Quick (QML) in one project. The widget set as of Qt 4.7.2 is woefully anemic, but other than that, it seems like a general improvement over using C++ for the entire UI. At least 90% of user interfaces (averaged over the world's applications; there are a few very graphics-intense apps that bring down the average) do not need the marginal speed improvement you can get by using C++ instead of QML. Qt does a pretty decent job at making it easy to go between native C++ widgets and QML code, so C++ developers get to focus on the parts of the GUI that need performance.

      What is in using QML for me? I get to offload most of the GUI development to a UX designer who is better at that sort of thing (and costs my employer less per hour of work). Then I get to focus on the novel and application-specific parts of the interface. I also get cleaner separation between those application-specific bits and the overall skin.

    5. Re:Ugh.... by glebovitz · · Score: 1

      I don't mean to rain on your parade, but we are developing a lot of QML/JS code and the development time is a fraction of doing the same thing in C++. In addition, we are finding that it is easier to train web graphic designers to use QML then to teach programmers graphic design. There are a lot more JS programmers out there than there programmers who know and use C++.

      We are also doing Windows Mobile Phone 7 development and XAML is a really good model. You still have to write code behind in C#. The model works well in separating the design from the code, but you still have to hack XML and C#. I am using both, and QML/JS is a much easier to learn and use.

      I read your statements, and they are very similar to what the COBOL programmers were saying to me in the 1980s "Oh this C and SQL stuff is fine for universities and researchers, but it will never catch on in the business world. I heard the same thing from the AS 400 developers in the early 1990s "real business wil run on mainframes, not this Sun server stuff."

      Oh and about the comment for a Qt 5 competitor. O am not suret the open source community needs, another C++ framework to dilute resources and add confusion to the community. Maybe a better idea would be to give this a chance and see if it pans out.

    6. Re:Ugh.... by Elledan · · Score: 1

      Maybe QML really is easier... I have been doing some Android development lately, and defining the UI in a separate XML file definitely has its advantages.

      As pointed out and as I have discovered during my own research into QML its feature set in 4.7 is pretty aenemic. If they can make it a carbon copy of the feature set of the Qt widgets, then it might be worth looking into :)

      --
      Site & blog: http://www.mayaposch.com
    7. Re:Ugh.... by Anonymous Coward · · Score: 0

      I don't mean to rain on your parade, but we are developing a lot of QML/JS code and the development time is a fraction of doing the same thing in C++.

      And it'll run dog slow especially with data-intensive UIs. Yes, I have tested this. Your little toy apps may be fine in QML but real apps are going to need something better.

    8. Re:Ugh.... by DrXym · · Score: 2

      I'd rather having nothing. I'm using Qt to write C++ code not to be a Javascript monkey. Looks like the Qt are trying to make themselves irrelevant with statements like:

      Actually QML is there to try to make it easier to develop apps by allowing people to declaratively define their UI and use minimal inline or external language for the binding. It's a perfectly sound practice, variants of which one can be found in various other GUIs, both in thick clients and web development. e.g. Flex,. XUL, XAML, JavaFX etc. For starters it means doing away with a vast amount of boilerplate, faster application prototyping, faster development build cycles, greater portability, less bugs caused by programmer error which ultimately leads to faster time to market and a higher quality product.

      I realise if you're too set in your ways to adapt that it might be easier to denigrate such efforts than appreciate their uses, but that's your problem not the platform's.

    9. Re:Ugh.... by Anonymous Coward · · Score: 1

      greater portability

      Wrong, QML will actually be less portable especially when Qt5 will require at least OpenGL ES 2.0. Kiss goodbye any support for embedded systems without OpenGL support and yes there are many.

      less bugs caused by programmer error

      In what way?

      I realise if you're too set in your ways to adapt that it might be easier to denigrate such efforts than appreciate their uses, but that's your problem not the platform's.

      I realise that to you a bunch of buzzwords and bling bling might be important but for those of us writing real desktop and embedded apps where performance is critical, this change is mostly useless. Hell even the Qt Creator guys are admitting they will barely be using QML and mostly sticking to QWidgets. If they won't even eat their own dog food, I'm not buying into it. This isn't even taking into account the dearth of widgets equivalents for QML.

    10. Re:Ugh.... by tibit · · Score: 1

      I think you didn't look at the code. First of all, QML is NOT Javascript. It is a declarative language that integrates seamlessly with Javascript. As for efficiency: I'd beg to differ. There's nothing inherent in the declarative framework that would make it less efficient than QWidget. QML has expressive power that makes legacy frameworks look almost silly. QML comes with a lot of demos. Try implementing some of them using out-of-the-box pre-QML APIs and you'll understand.

      The QLayout system is a complete nightmare -- to get anything that's less-than-trivial, you have to relegate to spreasheet layouting: make lots of extra rows and columns, and then span your widgets across several of them. And good luck if your widget needs to have visible elements outside of its boundary -- and no, it's not only about particle effects, how about highlighting, drag-and-drop/drag-and-clone, etc.

      I fully believe that legacy UI framework design decisions (ala GTK, Qt, WxWidgets) have seriously and negatively affected usability of common business applications (ERP systems, I'm talking about you). If you want to design clean, usable UIs using a legacy framework, you are pretty much back to using some sort of a hierarchical canvas (like QGraphicsScene) and laying out everything yourself. QML takes a lot of busywork out of that.

      --
      A successful API design takes a mixture of software design and pedagogy.
    11. Re:Ugh.... by tibit · · Score: 1

      That's a silly argument. I don't think you're laying out all the widgets by hand all the time, right? You're probably using Designer to produce .UI files for most of your UI. Guess what: QML designer is pretty much the same thing, but gives you much more expressive power. The QWidget/QLayout systems has inherent constraints that cannot be worked around by simply expanding the API. They needed a brand-new paradigm, and they delivered.

      All of the back-end functionality (models!) has to be done in C++ anyway, and you're free do develop custom visual elements in C++. In fact, you likely will end up developing custom visual stuff in C++ where you had complex QWidgets, but not for "silly" stuff.

      So far in Qt you had to pretty much subclass controls or widgets and write C++ code for simple UI elements like toggle switches, gages, indicators, etc. With QML, you can get simple controls without writing any code at all and using QML Designer (a plugin in Qt Creator).

      For complex views, like say a PCB layout, electrical schematic or a document editor, you'll still code it in good old C++.

      At least QML somewhat forces you to do clean model-view separation -- of course seasoned developers who know their stuff will do it naturally, but there's plenty of code out there where data is intertwined with visuals. I applaud that QML promotes clean separation of concerns here.

      --
      A successful API design takes a mixture of software design and pedagogy.
    12. Re:Ugh.... by tibit · · Score: 1

      Couldn't agree more. I will be getting our designer lady a QML/QMLDesigner tutorial in a week or so. That way I'll be getting ready-made user interfaces, with relevant functionality already built in, and I can focus on providing data models and state management for the application as a whole.

      --
      A successful API design takes a mixture of software design and pedagogy.
    13. Re:Ugh.... by Kjella · · Score: 1

      I came from a Gtk+ background, but am using Qt Quick (QML) in one project. The widget set as of Qt 4.7.2 is woefully anemic, but other than that, it seems like a general improvement over using C++ for the entire UI.

      My impression is that Qt Quick is another one of those things that's going to come full circle. First you go from a huge set of widgets (QWidget & decendants) to html/css (Qt Quick) and eventually you'll want to build the exact same widgets on top of that again for convienience. Oh well..

      --
      Live today, because you never know what tomorrow brings
    14. Re:Ugh.... by Desler · · Score: 1

      I think you didn't look at the code. First of all, QML is NOT Javascript. It is a declarative language that integrates seamlessly with Javascript.

      More accurately, QML is Javascript with extensions.

      As for efficiency: I'd beg to differ. There's nothing inherent in the declarative framework that would make it less efficient than QWidget.

      And yet with a simple search of "QML slow" you can find all sorts of examples of QML running slow. All sorts of people are seeing lagginess, etc in QML apps. The best the Qt people have shown have been little toy examples where there may be no noticeable difference. Get back to me when they have a full blown app that has lots of intensive visualization and show me that it has no efficieny issues.

      QML has expressive power that makes legacy frameworks look almost silly.

      Examples? It really means little to hear people throw out buzzwords and provide no examples of how it is more this or that.

    15. Re:Ugh.... by tibit · · Score: 1

      First of all, reimplementing most if not all Qt widgets in QML takes less code than original Qt widget implementations took, line-wise. And it's by a fairly large factor -- a reduction of 5-10 times. Just look at the Qt Quick Components for Desktop -- it's pretty amazing stuff when you realize that a table view is about 500 lines long. For your reference, src/gui/itemviews/qtableview.cpp is 3000 lines long, and it's not nearly as modular and tweakable as TableView QML element.

      The beauty and power of QML is shown in the fact that the TableView component's source code is not only fairly easy to understand, but it's very easy to tweak. I had to add per-column delegates for my project and it was a dozen lines or so, took about an hour without any prior QML experience. Good luck with modifying qtableview.cpp. Now I of course realize that there's no full feature parity between the two just yet, but they are alarmingly close. And if you consider source tweakability to be a feature in itself, I think that QML already wins over native Qt views. Even little details make life easier: suppose you want to tweak QTableView and cannot simply derive from it, but you have to modify the source. If you want to copy it over to your own project, you have to at least do a search-and-replace to change the damned class name everywhere. In QML, you change the damn file name and you're done. Add enough of those "little" improvements, and you get something that beats expressibility of C++ by a lot.

      Qt could have been much further ahead if they implemented the QML idea back in times of Qt 1.x... And no, I don't buy the argument that the platforms back then were too slow. They'd have had to spend more effort in optimizing things, but there's nothing inherent in QML that makes it slow. All the heavy lifting is done by C++ code or JIT-ed JavaScript anyway.

      --
      A successful API design takes a mixture of software design and pedagogy.
    16. Re:Ugh.... by Anonymous Coward · · Score: 0

      First of all, reimplementing most if not all Qt widgets in QML takes less code than original Qt widget implementations took, line-wise.

      Yes, and it will takes numerous man years to reimplement all your QWidgets in QML for what in most cases is negligible to negative impact. Yeah, who cares about bringing updates to your software, bug fixes, etc when you can reimplement the wheel instead for no gain!

      They'd have had to spend more effort in optimizing things, but there's nothing inherent in QML that makes it slow.

      Yeah, using an interpreted language for your UI glue code couldn't possibly have speed issues! Secondly, if QML is so great why are the only examples little toy programs? And why do the Qt Creator people even admit that they are only going to use QML sparingly? If QML is so great, shouldn't they just be dumping all their QWidgets for it?

      All the heavy lifting is done by C++ code or JIT-ed JavaScript anyway.

      And JIT-ed Javascript is still slower than C++.

    17. Re:Ugh.... by DrXym · · Score: 1
      QML is in QT 4.7. What QT 5 requires by way of graphics support is irrelevant. As for less programmer error - declarative code and minimal code within a proper garbage collected environment means less errors like point errors, memory leaks, casting errors etc.

      It's not about buzzwords. Declarative UIs with bindings are a pattern proven to work elsewhere and it will be proven to work in QT. It doesn't mean it is right for every application but it will do for a lot of apps either in full or partially.

    18. Re:Ugh.... by tibit · · Score: 1

      QML has expressive power that makes legacy frameworks look almost silly.

      Examples? It really means little to hear people throw out buzzwords and provide no examples of how it is more this or that.

      Look at any of the demos that come with it. Say the corkboard. Then implement using "bare" Qt.

      I have ported a database-driven application to QML, and I can't feel any speed difference between the declarative UI rendering the views and the QWidget views. There are perhaps problems when too many things are moving about at once, but I'm not trying to do that. The only motion is in following the mouse and doing flicks, and this performs as it should.

      --
      A successful API design takes a mixture of software design and pedagogy.
    19. Re:Ugh.... by Anonymous Coward · · Score: 0

      Qt5 will require at least OpenGL ES 2.0. Kiss goodbye any support for embedded systems without OpenGL

      No, this requirement does not preclude small systems with unaccelerated framebuffers. You can model such a system in OpenGL with a single quad and a texture than happens to match the framebuffer format. A small, simple, efficient ortho-only software implementation of OpenGL is also conceivable. Looking beyond that, today even low power ARM11 cores implement OpenGL ES 2.0. It is becoming the next VGA. Intel, AMD and ARM all build this capability into most of their cores now.

      If they won't even eat their own dog food

      It'd rather they not relegate the native C++ API to 'legacy' status as well. Just mandate parity and let both enjoy equal status; developers will ultimately decide the fate of QWidget and QML in any case.

    20. Re:Ugh.... by Desler · · Score: 1

      So if QML is so great why do the Qt Creator guys admit they will barely be using it in the Qt5 version of Qt Creator? The reason is is because it doesn't provide nearly the benefit that is claimed otherwise they'd be pressing full on into QML.

    21. Re:Ugh.... by Desler · · Score: 1

      Look at any of the demos that come with it.

      You mean all the little toy demos that aren't even remotely similar to the needs of a full blown desktop app? I'll believe it's so great when Qt Creator is implemented fully in QML. Oh wait, that's not going to happen as they admitted they will only be using it very sparingly. Since they don't eat their own dog food, I don't buy the hype.

    22. Re:Ugh.... by glebovitz · · Score: 1

      First Before you make sweeping comments, you should do a little research, because you are completely wrong. Hence the cowardly anonymous posting. The apps we developing are huge and run on some fairly light hardware. Turns out that QML is f..king fast and the few thing that aren't can be implemented in C++ and bound to QML. I don't believe you have done any testing. I think you are making this up. The data driven part of data driven apps in QML are implement in C++ you twit. That includes the XMLModel. Any other data driven apps are using implement in QAbstractItemModel in C++.

      Second, the QML Widgets are coming quickly. Qt components and MeeGo Ux Components are already here and they implement enough to do what you need. The features missing are easily implemented by adding to these components.

    23. Re:Ugh.... by tibit · · Score: 1

      Umm, qmlcreator is implemented in QML. Qt Creator is such a simple thing when it comes to visual design that doing it in QML will not expose any performance issues. It'll still use the same editor widget etc. This actually gives me idea to try it out, I'd love to see the reduction in code size. It may turn out to be a quick job for the main window, too.

      --
      A successful API design takes a mixture of software design and pedagogy.
    24. Re:Ugh.... by DrXym · · Score: 1
      That should be pretty obvious. Qt Quick / QML are an abstraction over Qt. It's kind of hard to write an development suite that generates, compiles, edits UIs for Qt and Qt Quick when you deny yourself access to the APIs you need to do that. A development environment is atypical, and not representative of what most apps require. I'd add that change for change's sake is bad. Why rewrite a tool when it works already?

      You may as well demand Oracle write Netbeans in JavaFX, or Microsoft write DevStudio in XAML.

  5. KDE5 by Anonymous Coward · · Score: 0

    Oh, no, now that KDE 4 was almost usable, we'll start over again with KDE 5.

    1. Re:KDE5 by Randle_Revar · · Score: 3, Informative

      KDE5 will not break the world like KDE4 did. Just as Qt5 will not break the world.

      http://aseigo.blogspot.com/2011/05/relax.html
      http://aseigo.blogspot.com/2011/05/qt5-kde5.html

      --
      Climate Progress - Hell and High Water
  6. This will kill KDE by VincenzoRomano · · Score: 1

    As kde developers will start thinking about and switching to kde5. I see another wave of bugs and instability, the same that made me switch from kdev4.1 to xfce. These architects get excited by new technologies and loose the focus on stability and usability. Let's see what will happen.

    --
    Maybe Computers will never be as intelligent as Humans.
    For sure they won't ever become so stupid. [VR-1988]
    1. Re:This will kill KDE by karper · · Score: 3, Interesting

      It's going to be a behind-the-scenes change and it's not as big a deal as the kde3kde4 change. Reference: http://aseigo.blogspot.com/2011/05/relax.html

    2. Re:This will kill KDE by Morose · · Score: 0

      I doubt it will kill KDE. Instead it will just return QT to more community development instead of commercial development (which, I seem to recall is one of the reasons people went with Gnome instead of KDE way back when, pre-GPL on QT). QT is completely forkable so there is no reason that if Nokia stops officially supporting it that someone else could come along ala X.org/X86.

    3. Re:This will kill KDE by Anonymous Coward · · Score: 0

      Oh. I thought KDE4 was supposed to kill KDE.

    4. Re:This will kill KDE by DMiax · · Score: 2

      Relax :) (blog post from one of the head developers of KDE)

    5. Re:This will kill KDE by Anonymous Coward · · Score: 0

      KDE is still alive?

      And I don't say this only due to the death of Qt. Software goes in simple-bloat-simplify pattern.

      KDE has been stuck in the bloat phase (along with out of control dependencies) for a long time.
      GNOME is there now.

      LXDM vs XFCE is the new KDE vs GNOME

    6. Re:This will kill KDE by IrquiM · · Score: 1

      They told you not to use KDE 4.1 as a primary desktop, but you did it anyways! It's your fault - not KDEs! (Which is not called KDE anymore anyways...)

      --
      This is blinging
  7. There will be no distinction between a Nokia... by Threni · · Score: 1

    > There will be no distinction between a Nokia developer or third-party developer.

    Or indeed not being a developer at all.

  8. zeus weapon misfiring badly, minions flee by Anonymous Coward · · Score: 0

    the whore of babylon has been rescued by the native elders. she has the papers, & is cooperating wholeheartedly with the disarmament mandate.

    1. Re:zeus weapon misfiring badly, minions flee by Anonymous Coward · · Score: 0

      I wish I was high so I could understand this.

  9. Re: switch to xfce by TaoPhoenix · · Score: 1

    Hi.

      I am a potential new linux user and my initial specialty/focus will be on the UI side. I have been considering looking into xfce as well. Do you think it's the new dark horse UI behind Gnome and KDE?

    --
    My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
  10. Is the lock in that strong? by NtwoO · · Score: 2

    The deal between Microsoft an Nokia has been a big topic with many opinions. The opinion that Microsoft actually needed a strong hardware platform for their OS more than Nokia needed Win Mobile for their phones is a strong contender for me. Maybe having a say in keeping Qt open is a clear signal that this is also truly the case. It could very well be that Nokia was keen for the partnering but is not ready to sell their soul and cut off all options for the future. ~

    --
    ! /* */
    1. Re:Is the lock in that strong? by operator_error · · Score: 2

      The annual (linux) Meego conference is in a few days' time, in San Francisco. Google News (search) reveals that the Nokia N950, the successor to the N900 will be _probably_ be announced at this conference.

      Nokia has never backed-off its support for Meego. Well, okay they have hyped and now focused development resources towards their M$ partnership, but to the extent possible given their current business strategies, they still support their prior open-source OS strategy. In other words, they haven't really backed-away from Meego, while they will support WP7 going-forward. (But in lieu of the recent M$ partnership, they need to hype M$, especially following that particular announcement).

      http://sf2011.meego.com/

      Vote with your feet folks. Meego is still a very good mobile OS worth buying and developing for; especially if you are developing for your own purposes. Today's news reinforces this.

    2. Re:Is the lock in that strong? by gbjbaanb · · Score: 1

      I guess people are voting with their feet - by not buying WP7 :)

      We'll see what happens, I think WP7 will continue to bomb even after the $1bn bung from MS runs out, and then Nokia will at least have the opportunity to ressurect itself with its old ace card, maybe beefing it up for non-phone systems. The danger is that, good though Meego is and could be, Android will steal all its market before it has a chance to shine. That's a problem they'll have to deal with while they attempt to flog WP7 devices.

    3. Re:Is the lock in that strong? by CRCulver · · Score: 2

      Elop has announced that Nokia is trying to hand Meego over to another company like LG and does not believe Meego has a place in its longterm strategy. Also, there's a big controversy that this new "N950" model will feature just Maemo with a few updates applied, and it does not meet the Meego standards. There's plenty of coverage of the controversy over at Maemo Weekly News.

  11. Re: switch to xfce by Tolkien · · Score: 1

    I've used xfce and it's pretty nice. The last time I did It was extremely bare bones, you added only what you wanted. I think that was their design philosophy or something so it's a safe bet, I think.

    --
    how is babby formed?
  12. Javascript? by Anonymous Coward · · Score: 0

    Said that the code needs to use the GPU. Good.

    Then kill that performance with JS?

    1. Re:Javascript? by Entrope · · Score: 1

      The vast majority of user interfaces spend more time waiting for user input than they spend drawing to the screen. Of course, users notice redraw time more when they are the ones waiting. But I've used Qt on a small device (a several-year-old cell phone application processor), and the things that made that UI slow are the animations that were chosen for the UI -- animations that are drawn by the CPU and GPU using compiled code, but with durations that were a little bit too long for impatient users like me.

      There is a (mostly overlapping) vast majority of user interfaces that are less responsive than possible because they block the UI during long-latency operations, but that has little to do with the language used to implement the UI, and more to do with how easy it is to kick off background tasks from the UI and push those results back to the UI. (QML has a benefit here because it makes that easier.)

      Plus, JavaScript JITters are getting better every few months.

    2. Re:Javascript? by 21mhz · · Score: 1

      Then kill that performance with JS?

      You surely save a lot of CPU cycles on laying out 100k times per minute all those views and dialogs painstakingly hand-coded in C++. Or wait... may I suggest to optimize what really needs to be optimized, and enjoy the productivity boost in creating the rest, not to mention separation of tasks between UI design and application logic programming?

      --
      My exception safety is -fno-exceptions.
    3. Re:Javascript? by Lunix+Nutcase · · Score: 1

      may I suggest to optimize what really needs to be optimized, and enjoy the productivity boost in creating the rest, not to mention separation of tasks between UI design and application logic programming?

      Of which you can already do now without the need of QML and its overhead. Plus the Qt people keep trying to skirt around the performance issues when people kept repeatedly asking about it and considering how many posts you get about poor performance with QML apps through simple Google searches I can see why. Factor in how many custom widgets people use in desktops apps now and I can't possibly see most people wasting the time and effort to rewrite in QML.

    4. Re:Javascript? by tibit · · Score: 1

      Porting a QWidget to QDeclarativeItem is so easy that it could be considered a janitorial task in many projects. Plenty of simple custom QWidgets can be reimplemented in QML with a significant drop in code size, so there's actually a good reason to do that. Especially if you have a designer on staff who got Qt Quick training and can provide you with an "endless stream" of custom, appealing widgetry.

      There's nothing architecturally wrong with QML. The current implementation surely has performance corner-cases, just like early Qt 4.x series had, especially before 4.4. The performance issues will be worked out, there's no fundamental reason why QML should perform worse than a QWidget-based ui. Heck, I've found quite a few cases where QLayout-based UIs were stuttering when you resized the windows or dragged splitters -- the QLayout/QWidget infrastructure is seriously broken if you use native widgets, like you had to on OS X for example until very recently.

      --
      A successful API design takes a mixture of software design and pedagogy.
    5. Re:Javascript? by Desler · · Score: 1

      Porting a QWidget to QDeclarativeItem is so easy that it could be considered a janitorial task in many projects.

      Well then why haven't you ported all the QWidgets over for us by now? It's so quick and easy, right?

      Plenty of simple custom QWidgets can be reimplemented in QML with a significant drop in code size, so there's actually a good reason to do that.

      That's great if all you ever used were "simple" QWidgets. Many people rely on much more than "simple" widgets for real apps.

      The current implementation surely has performance corner-cases, just like early Qt 4.x series had, especially before 4.4.

      Thus making it unusable for people who need high performing apps. Most people aren't going to rewrite things in QML just because they are promised that years down the line it will stop being laggier and slower than their current QWidget-based programs.

      The performance issues will be worked out, there's no fundamental reason why QML should perform worse than a QWidget-based ui.

      Sure, if we ignore the overhead over interpreted code.

      Heck, I've found quite a few cases where QLayout-based UIs were stuttering when you resized the windows or dragged splitters

      And you've reported these issues?

      the QLayout/QWidget infrastructure is seriously broken if you use native widgets, like you had to on OS X for example until very recently.

      In what way?

    6. Re:Javascript? by tibit · · Score: 1

      The performance issues will be worked out, there's no fundamental reason why QML should perform worse than a QWidget-based ui.

      Sure, if we ignore the overhead over interpreted code.

      There's no "interpreted code" anywhere in QML. Whatever parsing there is, is done only once. Javascript is executed by a decently performing JIT-ting runtime -- same one that powers WebKit. Instantiating a QML element does not AFAIK cause any textual source code to be parsed or JIT-ted more than once. Surely there will be some overhead due to parsing QML at application startup, but this can be tweaked by doing lazy instantiation via the Loader.

      --
      A successful API design takes a mixture of software design and pedagogy.
    7. Re:Javascript? by Anonymous Coward · · Score: 0

      Oh, your several-year-old cell phone had a GPU? I highly doubt that, even many of the current crop of rather high-end android phones have that nowadays.

    8. Re:Javascript? by Desler · · Score: 1

      Surely there will be some overhead due to parsing QML at application startup

      So that doesn't explain why QML apps are also laggier while running. Also, I like how you ignored everything else I said. If porting all the QWidgets already written to QML is such an easy task then you have all of the ones that ship with Qt now ported over by next week, right?

    9. Re:Javascript? by tibit · · Score: 1

      Direct porting to QML means that the code still stays in C++. One could start porting QWidgets by designing a small shim class that interfaces the exposed QWidget API to the underlying QDeclarativeItem APIs. Most of what the shim would do is just translating event data types. I've done it as a proof of concept, and there's nothing to it. You literally derive from a WidgetShim instead of QWidget, and it "just works". There's no difference in performance, since the widget code is exactly same, and the shim is mostly trivial data shuffling stuff. If the widget is referencing any other widgets directly (like view delegates), you have to manually intervene, but for most widgets it's not an issue and a shim class suffices. A cleaner port would mean that you manually or with a code rewriting script change QWidget API calls to QDeclarativeItem ones.

      What Nokia wants to do instead is to reimplement all widgets in QML script (not C++), to make them less monolithic and more tweakable, and to interoperate better with rest of QML. This is precisely what the QML Components for Desktop project is all about. I'm sure that whatever bottlenecks or shortcomings are exposed by that project get to influence Qt Quick.

      Is there a technological risk in jumping to Qt Quick right away? Sure, it's a new code base and it'd be foolish not to appreciate that mature QWidget code base is almost by definition safer. But with every risk there are rewards, and for my projects Qt Quick is the right choice.

      I don't immediately see how typical business applications would suffer at all from Qt Quick: their interfaces are typically quite simple. I'm looking at Apple Mail's main window and it has a toolbar, a treeview sidebar showing the mail folders, another treeview for messages/conversations in the folder, a splitter handle, and the message viewer. There's also a sliding listview for mail activity, and three buttons to control that and a little popup menu.

      If we assumed that Apple Mail was written in Qt, and it was done cleanly, then the only major task in porting the main window would be to implement TreeView -- this hasn't been tackled that by the Desktop project. The rest is essentially doing design work: setting up properties for the TreeViews and delegates, and just laying out a couple of widgets. The underlying data models would stay untouched -- again, assuming the work was done right in the first place.

      --
      A successful API design takes a mixture of software design and pedagogy.
  13. Windows Phone 7 and Qt... by musicmaker · · Score: 1

    Why exactly are these two things related? Qt is a completely different development line from WP 7, it's a windowing toolkit not a mobile OS. Show me some good news about MeeGo, and I might, just maybe, get a bit excited.

    Sure, you could go on about how Qt is at the foundation of MeeGo, but it's at the foundation of lots of other things too, like KDE amongst others. Good news for Qt does not imply good news for MeeGo. In fact, possibly quite the opposite, as I can imagine a scenario where Nokia had left over contracts with outside vendors, and maybe a few Linux oriented staff that didn't get rid off, so they're just redirecting them at Qt and taking them off MeeGo.

    --
    Everyone is living in a personal delusion, just some are more delusional than others.
    1. Re:Windows Phone 7 and Qt... by CRCulver · · Score: 1

      In a recent interview with Elop (no longer have the link, sorry, maybe someone else does) he said that Nokia is looking to pass Meego to some other company, for example, LG. Nokia's commitment to Meego is finished.

    2. Re:Windows Phone 7 and Qt... by horza · · Score: 1

      Give it to Samsung! They are already streets ahead of Nokia when it comes to hardware, give them Meego and I can see them becoming the number one handset manufacturer.

      Phillip.

      --
      Property for sale in Nice, France
    3. Re:Windows Phone 7 and Qt... by Microlith · · Score: 1

      Samsung doesn't want to work with MeeGo, at best they'll meet up at the Linaro level. LG has already hopped on the handset working group.

    4. Re:Windows Phone 7 and Qt... by Anonymous Coward · · Score: 0

      Because Nokia primarily sell mobile phones, they have been using QT as a toolkit to develop apps on Symbian and Maemo/Meego, since the WP7 deal it looks like Nokia is going to slowly kill off Symbian and most likely future plans for Meego so it looks like they would have no use for QT since MS won't allow it on WP7.

  14. How do you pronounce Qt anyway? by Anonymous Coward · · Score: 0

    Is Qt pronounced "Que Tee" or "Cute"? (I think the official pronounciation is "Cute", but how do most people say it?)

    1. Re:How do you pronounce Qt anyway? by Tolkien · · Score: 1

      I personally say Queue Tee. I would say Cute if it were spelt Qute.

      --
      how is babby formed?
  15. Best GUI library for C++ by Script+Cat · · Score: 1

    If you're writing software in C++ that's portable, which GUI library would you use at the present time?

    1. Re:Best GUI library for C++ by EdgeyEdgey · · Score: 1

      For small use FLTK
      Or more options here

      --
      [Intentionally left blank]
    2. Re:Best GUI library for C++ by halfdan+the+black · · Score: 0, Offtopic

      I take it you've never had the pain of using a QT app on OSX, QT is an absolute disaster on OSX, AND looks pretty dated on Win7. If you want your app to be taken seriously, the UI NEEDS TO BE NATIVE, and thats NOT QT. By native, IU should be WPF on Windows,Win Phone / Cocoa on OSX,iOS and GTK on Gnome and QT on KDE, Java on Android. UIs need to be native, don't short change your users by giving them something that looks completely alien on every platform other than KDE.

    3. Re:Best GUI library for C++ by rwa2 · · Score: 2

      Good call... so in other words, something use something like http://www.wxwidgets.org/ for cross-platform development while still hooking into native widgets?

    4. Re:Best GUI library for C++ by Anonymous Coward · · Score: 0

      Whatever you find easier to program with and whatever makes you more productive. Qt, Fox Toolkit, Wxwidgets, FLTK and many more.

    5. Re:Best GUI library for C++ by jopsen · · Score: 1

      Qt on Gnome is great... And qt on Windows Xp was also great... Haven't tried Vista or 7 though...

    6. Re:Best GUI library for C++ by Timmmm · · Score: 2

      I've used Qt on OSX. It works fine. And Qt looks native on all platforms so I have no idea what you're talking about...

    7. Re:Best GUI library for C++ by halfdan+the+black · · Score: 1

      QT fakes out the look of the native OS with a "theme". On any platform, you can use any theme, for example, on OSX, I can use a KDE theme. Problems are this "theme" might look superficially similar to the underlying toolkit, but nothing really works right. On OSX, text is never lined up, drop boxes are always off, toolbars just look weird and alien, QT basically looks kind of Frankenstieny on OSX and Windows. Its what is called the "uncanny valley" effect, where something looks close, but ends up looking just bizarre because countless small inconsistencies. There is no practical way to deal with all these inconsistencies when you fake out the native OS with a theme. The only way to do it right is to use the native controls, which QT DOES NOT.

      Basically what I'm saying is that there is no such thing as a decent "cross platform" UI library, the UI is so closely tied to the user experience on a particular platform that you can't abstract it or fake it away as to treat each OS exactly the same.

      For example, take a look at Maya, it is probably the only big commercial app written with QT. They use their own theme on every platform, Maya does not even resemble a standard Windows or OSX app -- they don't want to have the user experience I've described above. There are some other commercial apps that use QT, but ONLY on Linux. Skype uses QT on Linux,Cocoa on OSX, and WPF on Windows.

    8. Re:Best GUI library for C++ by Timmmm · · Score: 3, Informative

      > The only way to do it right is to use the native controls, which QT DOES NOT.

      I think you have not used Qt for a long time...

      http://en.wikipedia.org/wiki/Qt_(framework)#Use_of_native_UI-rendering_APIs

    9. Re:Best GUI library for C++ by Anonymous Coward · · Score: 0

      Sorry, but you're very wrong about this, Qt runs native on any operating system, that's the whole point of Qt, it's not a port like Swing (on java), it runs with the Operating system APIs, and It looks native, I have an application running on Linux, Windows 7, XP and OSX (yes Mac) and looks native, even in Mac the integrated menu works as expected, and it merge the Quit options as well,

      I think you missed the whole point of the cross platform frameworks, I think you should reevaluate your statement of being taken seriously, a LOT of "serious" applications that are portable used somekind of framework like Qt.

    10. Re:Best GUI library for C++ by jockm · · Score: 1

      Actually no. Take a look at what they say:

      Qt uses the native graphics APIs of each platform it supports, taking full advantage of system resources and ensuring that applications have native look and feel

      They are saying they are using the native drawing layer, not the native controls. There is a huge difference. The last QT App I used still didn't support OSX services. Which it would if it were using native controls.

      --

      What do you know I wrote a novel
    11. Re:Best GUI library for C++ by Desler · · Score: 1

      Qt doesn't use native widgets. They never have. What they have recently changed is using the native drawing APIs. That is not the same thing.

    12. Re:Best GUI library for C++ by Desler · · Score: 1

      If by "runs native" you mean it has in the last couple of years moved to use the native drawing APIs of the platform, yes, but it doesn't use the native widgets if that is what you are trying to imply. And for the longest time Qt just faked the native look with themes before using the native drawing APIs.

    13. Re:Best GUI library for C++ by tibit · · Score: 1

      It doesn't "fake" the look. It uses the visuals drawn by native APIs on both Windows XP and up, and on OS X. You can't enable an OS X look in KDE simply because Qt doesn't have the code that implements the look, it politely asks the Cocoa or Carbon API to do the drawing for it.

      Use of native controls is something I shun because as soon as you get a lot of them, you run into serious performance issues. Try having a thousand native-widget OS X buttons in your window, and see how fast they respond. By dropping the native widgets and using a so called alien, styled widget, Qt actually provides better performance than underlying OS X APIs, who'd have thought.

      --
      A successful API design takes a mixture of software design and pedagogy.
  16. QT5 should drop MOC and adhere to standards by whiteboy86 · · Score: 0

    Then we reconsider using it.

    1. Re:QT5 should drop MOC and adhere to standards by DMiax · · Score: 2

      Qt already adheres to standards. MOC is just a boilerplate generator and the actual code is compiled with any standards-compliant C++ implementation.

    2. Re:QT5 should drop MOC and adhere to standards by halfdan+the+black · · Score: 2

      Don't think it really can drop MOC or something like as still be a viable UI library.

      Dynamic dispatch is pretty fundamental in event driven UIs, and not sure if C++ can really provide such a concept. Thats why we need more dynamic languages like JScript/Python/Objective-C/C# for this type of programming.

      I'm sure there are things C++ is good for, but its not something as dynamic as UIs.

    3. Re:QT5 should drop MOC and adhere to standards by 21mhz · · Score: 2

      We as in who? The "template metaprogramming" weenies who could not understand for a decade why C++ is a train wreck?
      Don't bother; "we" the practical developers creating real-world maintainable software don't need you on our projects.

      --
      My exception safety is -fno-exceptions.
    4. Re:QT5 should drop MOC and adhere to standards by Anonymous Coward · · Score: 0

      "Practical developers", who? The "practical developers" who can't use C++ because "it's too hard"; or those, who constantly try to be smarter than they are, and fail with tools that don't babysit incompetent developers? Oh, no, pointers!

    5. Re:QT5 should drop MOC and adhere to standards by Anonymous Coward · · Score: 0

      Amen to this. C++ is a damn nightmare which Qt thankfully completely hides away so you don't have to deal with it.

    6. Re:QT5 should drop MOC and adhere to standards by Anonymous Coward · · Score: 0

      Well, MOC does generate standard C++ so I don't see why it's such an issue. It would be great if everything would be part of a modern, open and standard languaje, but I can settle for some add-ons in the real world. Just the signals-and-slots mechanism is enough for me to accept MOC, IMHO it's way more readable and simple than listeners, inner classes, function pointers and other alternatives.

      Also, the core data structures beat the STL and JAVA in both functionality and, most of all, documentation. So I still don't

    7. Re:QT5 should drop MOC and adhere to standards by tibit · · Score: 3, Informative

      C++ simply does not provide the introspection needed for a major application development framework. If it did, you could drop MOC. The way it stands, moc basically generates introspection tables because the out-of-touch [expletive deleted] folks who design C++ couldn't be bothered. That's my take on it.

      Every time you interface C++ code with any sort of an interpreted or JIT-ed language, you have to generate "bindings" using an external tool precisely because C++ lacks facilities for code to know about other code. Qt folks were nice enough to maintain such a tool themselves and to make it a core part of their process. I don't consider it a bad thing. QMetaObject system makes it fairly easy to expose QObjects to any other language that's either interpreted or JIT-ed.

      --
      A successful API design takes a mixture of software design and pedagogy.
    8. Re:QT5 should drop MOC and adhere to standards by tibit · · Score: 2

      It's not even about template metaprogramming. Template metaprogramming simply does not provide several facilities that are make-or-break for language binding generation. C++ does not have built-in facilities needed by binding generators, this has nothing to do with Troltech/Nokia's developers "ineptness". Guess why swig still exists? Hint: because whoever designs C++ lives on a little cloud-9 where you don't interface with anybody who doesn't use C++. It's a basic deficiency of current C++ spec, and there's no way around it other than running a code generator external to the compiler.

      --
      A successful API design takes a mixture of software design and pedagogy.
    9. Re:QT5 should drop MOC and adhere to standards by Anonymous Coward · · Score: 0

      WTF?
      It IS standard. The MOC is just a code generator to generate plain C++ code that would be extremely painful to write yourself.

    10. Re:QT5 should drop MOC and adhere to standards by 21mhz · · Score: 1

      Why, it can be done with some template classes, especially with variadic templates accepted into the standard this year. Except, the declaration syntax would be far more ugly, the compilation time would increase by orders of magnitude, and if you screw up, the error messages won't be much less arcane than what you get from moc-generated code.

      --
      My exception safety is -fno-exceptions.
    11. Re:QT5 should drop MOC and adhere to standards by 21mhz · · Score: 1

      because whoever designs C++ lives on a little cloud-9

      You could have put the period here. They are also oblivious about such bleeding edge innovations as shared libraries and standardized ABIs.

      --
      My exception safety is -fno-exceptions.
    12. Re:QT5 should drop MOC and adhere to standards by Anonymous Coward · · Score: 1

      We as in guys who don't want a stupid non-standard moc-to-cplusplus-precompiler messing around our make scripts.
      And if you say C++ is a train wreck, perhaps you should take a look at how C++0x has improved things.

      Qt has forced this "our way or the highway" mentality on developers. Want signals and slots? No, you cannot use your custom template implementation that would make things much easier, you need to do it via the MOC. Properties? The same thing. And don't forget that if you read the code and do your own thing, it'll be rendered obsolete the next time we change the MOC version (you know, like every fucking update).

  17. offloading dev costs? by isnotimportant · · Score: 1

    When they bought trolltec they planned on using qt in their phones. What incentive is there to continue development of qt when they plan on using winmo on their upcoming models? do they plan on utilizing "third-party" developers to drop/reduce development costs on qt?

    1. Re:offloading dev costs? by Anonymous Coward · · Score: 0

      They provide commercial support for it.
      http://qt.nokia.com/support/

  18. Re: switch to xfce by horza · · Score: 1

    I enjoy xfce4 but am happy with KDE4. It's not a dark horse, just another alternative. On a standard PC I would recommend Kubuntu, but on a netbook it's a trade-off time vs speed. If you want something that just works then install Kubuntu, though it's a bit heavy and slow, but if you have time to tweak (make sure you install ROX) and want the extra horse-power out of it then install Xubuntu. It is not that one is better than the other, it's just a trade-off. They are both great.

    Phillip.

    --
    Property for sale in Nice, France
  19. fraud? by Anonymous Coward · · Score: 0

    In other hand, Nokia is now controlled by MS. And MS has been successful in making people believe MS is really supporting something (open standard for Office, Java, Moonlight, HTML5) but in reality digging grave for them.

  20. Re: switch to xfce by Tolkien · · Score: 1

    Oh, I didn't mean to imply that Xfce is a dark horse, just that it itself is a safe bet. :)

    --
    how is babby formed?
  21. Why is Nokia spending money doing this? by mr+crypto · · Score: 2

    As much as I'd like to believe that it's because they are good people doing good things, why are they putting money into this, and how long can we expect them to keep doing so?

    1. Re:Why is Nokia spending money doing this? by Anonymous Coward · · Score: 0

      Keep your enemies close. What OS do you think Nokia's best engineers work on? Use QT as a training/proving ground, and pick the best of the litter for your commercial dev group. Double benefit: employee training/filtering, and a competing OS remains relatively ragged and slipshod compared to your commercial offering. Side benefit - you can always fall back to plan B if plan A blows up in your face. Cynical? Yes. But if I can imagine such a strategy in five minutes, imagine what executives who think about stuff like this all day come up with.

    2. Re:Why is Nokia spending money doing this? by suy · · Score: 1

      As much as I'd like to believe that it's because they are good people doing good things, why are they putting money into this, and how long can we expect them to keep doing so?

      There is a rumor about this. Some people thought that it would be possible to add S40 support in Qt. I thought that S40 phones are too small and cheap to run powerful apps, and the demand for applications for this platform is quite small, but... Stephen Elop and Mary McDowell visited Qt headquarters. McDowell is the head of "mobile phones", which is the feature phone (or "dumb phone") division in Nokia. Given that Windows Phone is only targeted at high end, some of the market space that Symbian covered has to be swallowed by S40 too.

      Given that Nokia is also very serious about the emerging markets (India, China, etc.), where they still have a strong position, this makes some sense. I'm not specially excited about this and is just a rumor, but makes sense. There is also MeeGo. I think they would be very stupid to drop it completely, specially if they have to pour money to release one device and maintain it first.

    3. Re:Why is Nokia spending money doing this? by Locutus · · Score: 2

      well it's not a plan to fragment the Qt developers and projects and it's not so that if that were to happen yet another cross platform dev tool would benefit Microsoft and their plans for Windows Phone 7, 8, etc app development. No, it's not that. Look, over there! Ice cream!

      it does seem strange that Nokia sold the rights and licenses to collect revenue from customers yet retained control of the Qt development with little to no form of income from it. But then there's this poison pill they agreed to when purchasing Qt and the only company who would care a bit about Qt getting set free is Microsoft... well, it does make one wonder about all this. After all, a dead Qt is worth more to both Nokia and Microsoft than a lively and there's only one way to kill it and that's via starvation. How do you starve Qt out of existence? You can't do it directly or there would be an up roar and would possible even trigger Qt's freedom. Nope, you've got to starve it without anyone knowing that's what you plan on doing. Announcing big changes and new versions over a short period is a good start. Throw in some incompatibilities, reduce the platform support and you're on your way. So does Nokia have a good reason to be doing this and putting in the money? Are they putting in much money? Since they are run by a Microserf and sold their sole to Microsoft they no longer can be trusted at their word. IMO

      LoB

      --
      "Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
    4. Re:Why is Nokia spending money doing this? by Anonymous Coward · · Score: 0

      You take a good developer who joined Qt to work with smart people on an open-source project called Qt and shoved him into a .Net project?

      Yeap, that is going to work... He will happily jump on the opportunity to move to another town, give up on the stinking Qt to switch to .Net and embrace the proprietary development model.

    5. Re:Why is Nokia spending money doing this? by Anonymous Coward · · Score: 0

      Because they want to be an independent leading smartphone manufacturer.

      Using an operating system done by someone not within your company (and someone not designing your hardware) is not exactly independent (or good for your - or their - sanity, for that matter).
      Writing your own operating system from scratch isn't cost effective anymore (although they kind of still do that, too) and how do you attract developers to it, given that the programs then don't run on any other platform then?
      So they end up with the only real option: jointly develop operating system and tools with all others, to common standards, using a license that allows them to change whatever they want in their distributed version and distribute it. Eventually "everyone" will use it and they benefit from net effects.

    6. Re:Why is Nokia spending money doing this? by Anonymous Coward · · Score: 0

      Nokia are all about their 'Ecosystem' now. Hardware doesn't matter, they want developers to write for their phones (Nokia has sold hundreds of millions of phones capable of running QT apps) already in existence. They've completely dismissed the fact that they've pissed everyone off by announcing the 100% jump to WP7. But that's Nokia for you, they're doing it because they're deluded.

      Expect QT to be k

    7. Re:Why is Nokia spending money doing this? by ecki · · Score: 1

      To learn from the former Trolls how to create great software. The framework is important, but so are the people working on it, and how they get things done.

    8. Re:Why is Nokia spending money doing this? by Anonymous Coward · · Score: 0

      As do all other MS so-called engineers.

    9. Re:Why is Nokia spending money doing this? by ecki · · Score: 1

      You're paranoid. Plus the poison pill agreement is not relevant anymore now that Qt is under the LGPL (it was drafted before the license change). Check the work on open governance for Qt.

    10. Re:Why is Nokia spending money doing this? by Locutus · · Score: 1

      paranoid? on the contrary, over 20 years of experiencing Microsoft's business practices back my distrust that Qt has not been part of the Nokia-Microsoft marriage. As I said, the software can be run into the ground by misdirection so it only matters who controls it and Nokia kept control.

      LoB

      --
      "Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
  22. I haven't been worried about it by trawg · · Score: 1

    I've written it off as more or less completely irrelevant

    1. Re:I haven't been worried about it by Anonymous Coward · · Score: 0

      Just like the world never worried about you or your opinion in the first place.

    2. Re:I haven't been worried about it by mr_da3m0n · · Score: 1

      Parent is slightly harsh but it is true. just because you think Qt is irrelevant doesn't make it so at all. Qt is still a hugely used toolkit, and in my humble opinion, one of the best. Just because you don't use it doesn't mean it is irrelevant.

  23. Missing entry in list by Anonymous Coward · · Score: 0

    1. Re-architecture our graphics stack
    2. Base all Qt ports on Lighthouse
    3. Modular repository structure
    4. Separate all QWidget related functionality into its own library

    5. Publish a revised version of the QT4 Dance

  24. Kind of biblical joke by Anonymous Coward · · Score: 0
    I think it's a joke. Whore of Babylon = Nokia (went with Microsoft). Native elders = people in Nokia who realised that Elop may have screwed the pooch. They have persuaded Nokia (who controls QT, aka the papers) to release them and co-operate with the Open Source community.

    Yes, it's obscure. No, I don't know why the writer did it. Perhaps he's testing some "translate into New testament biblical imagery" software. Or, indeed, he's on something.

  25. The future of Qt by maestroX · · Score: 1

    Ow gawd. Styling of Qt quick resembles Symbian.

    1. Re:The future of Qt by Anonymous Coward · · Score: 0

      How exactly?

  26. PROTIP by Anonymous Coward · · Score: 0

    qtconfig lets you change the "look" of Qt applications, at least on *nix. There are settings to mimic the current GTK theme and engine, and the Windows XP look. Not sure about others, though.

  27. So long as the new proprietary base is there by Anonymous Coward · · Score: 0

    So long as the new .net proprietary base is in place, you can develop for any microsoft target you like.

  28. N900 and KDE by Anonymous Coward · · Score: 0

    The N900 is disappointment:
    * GPS is useless (with latest firmware I had to wait minutes for the GPS to start),
    * front facing camera is low quality and it make you look ugly (due to a low focal length),
    * it needs to be charged every night,
    * video-out was VGA quality (not really useful for presentation or slideshow on external devices).

    I hope that N900 with Qt/KDE apps would be a lot better.
    KDE on OpenSuSE is super fast on any computer (4 years old laptop, 6 years old desktop, netbook, and 1 year old laptop) than KDE on Ubuntu.
    KDE on Ubuntu Linux ("kde-full" too) is a lot slower even on 4-CPU AMD or on Intel i7 machines with modern ($200+graphics).

    So N900 has enough power to run Qt/KDE if it is done well (like in OpenSuse).