Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
GUI Handhelds KDE Graphics Software Hardware Linux

Nokia's Maemo Switching To Qt 182

Posted by timothy from the on-the-qt-but-not-very-hush-hush dept.
suka writes "During a keynote at the Gran Canaria Desktop Summit, Nokia's Quim Gil announced that a future release of Maemo is going to be built around Qt. Maemo Harmattan is going to switch away from GTK+ / Hildon, derStandard.at reports from the conference." Michael Pyne also writes with a post describing day one of the conference from a KDE perspective.
This discussion has been archived. No new comments can be posted.

Nokia's Maemo Switching To Qt More

Nokia's Maemo Switching To Qt

Comments Filter:

  • N900, please (Score:2, Interesting)

    by yk4ever ( 1110821 )
    That's all fun and games, but why are there no new products in the Internet Table line? C'mon, it's been almost 2 years since N810. The OS lives while the hardware was abandoned? Weird.

  • Hardly surprising, considering Hildon really wasn't very good. Sluggish, clumsy, and tending to waste a lot of very precious screen real estate - not that I see how switching to Qt changes any of those things. Still, it sounds like they're basically throwing the whole UI and all the software written for it out, and that sucks. I've long been tempted to write a little music toy app to run on my N800, but I should probably just buy an iPhone or a Pre (given that I don't actually carry the N800 around anywhere

  • I wonder about this (Score:4, Interesting)

    by erroneus ( 253617 ) on Saturday July 04, 2009 @06:45PM (#28583307) Homepage

    There is a lot of software for the Nokia N810 and below. Switching out to a new UI means a lot of stuff will either get uprooted or there will be a lot of libraries loaded into the machine's precious little memory.

    Still, if the developers of software port over to the new environment quickly enough, it won't matter but I can't imagine things will be quick enough.

    What can be done under Qt that can't be done under GTK? Is Qt more efficient in some way? What are advantages of Qt over GTK? I've never been clear on the differences... I just know they are different.

    • What can be done under Qt that can't be done under GTK? Is Qt more efficient in some way? What are advantages of Qt over GTK? I've never been clear on the differences... I just know they are different.

      Personally, I prefer Qt because of the superior documentation. I think Nokia prefers Qt because they own it now. It's sort of like when Microsoft bought Hotmail, and moved the servers from FreeBSD to Windows. It wasn't because it was better, but because it was theirs.

      • That's a really bad example... or perhaps a really dark example. In your example, that move was rather poorly done initially. They had all sorts of problems as Windows simply couldn't handle the task. Windows had to evolve to the task and as I understand it, the change was only superficial with BSD still on the back end or has that changed since I last heard?

        At the very least, if you are accurate in your parallel, then that forebodes a dark and troubled time during the change over. Of course they would

    • Re:I wonder about this (Score:4, Informative)

      by abigor ( 540274 ) on Saturday July 04, 2009 @07:08PM (#28583413)

      Qt is not just a gui framework. It provides a massive amount of extra stuff. Browse the documentation: http://doc.qtsoftware.com/4.5/index.html/ [qtsoftware.com]

      Note the WebKit integration, multimedia framework (Phonon, which was a part of KDE and later folded into Qt), OpenGL support, etc. etc.

      Comparing it to GTK is like comparing a full-fledged desktop like KDE or Gnome to Blackbox.

    • Re:I wonder about this (Score:5, Informative)

      by ricotest ( 807136 ) on Saturday July 04, 2009 @07:25PM (#28583519)

      First and foremost Qt is not just a widget toolkit. It is a full development environment: it has a build system (qmake), a fully-developed IDE and widget layout editor (Qt Creator) and many, many extra libraries. To quote just a few examples, there are classes to handle tray icons (whether in KDE, GNOME, Mac OS X or Windows), classes for running TCP servers, integration with the Phonon media framework, the WebKit browser, SVG, databases, multi-threaded code and even scripting support using QtScript, an implementation of ECMAScript (JavaScript).

      Qt is written in C++. GTK attempts to do object-oriented code in C and the result is a mess of explicit casting and macros. Seriously, most GTK C code looks horrible and is far less terse than the equivalent Qt program. This is mitigated when Python or Perl is used, but then you're sacrificing speed. With Qt writing C++ is basically as easy as using Java, C# or any other 'modern' language. All of the nasty stuff is taken care of. For example, Qt code is generally cross-platform.

      Its signal and slot system is also very powerful. For example, you connect a button's click() signal to the QApplication's quit() slot, and the button will cause the app to close when clicked. These signal/slot pairs can even be set via the Qt Creator IDE, just like Visual Basic! Or you might start up a webpage download and assign a slot to handle the signal sent when the page has been downloaded. Qt's signal/slots are introspective and modifiable at runtime, and you define new signals and slots just like you define new methods for a C++ class. The drawback there is that Qt programs require a pre-processing pass by moc (the meta-object compiler), in order to generate meta-data for runtime signal/slot manipulation, and to offer some syntactic sugar around Qt's features. As a side-effect, Qt adds syntactic sugar for features some might find questionable, for example adding a foreach() loop for lists.

      The build system, qmake, is quite simple: you list your source files, libraries and headers to link in a short configuration file (qmake can even generate this for you). qmake then generates a makefile from this data. This is useful as it also includes the 'moc' pass, but can be constrictive in some cases. You are, of course, not obligated to use qmake in your Qt project.

      As far as widgets go, Qt's are comparable with GTK or any other toolkit out there. Qt does a better job of looking good on non-Linux platforms, such as Windows. It has a simple but flexible widget system that is much easier to use than GridBagLayout or any of Swing's more poweful layouts.

      The main issue with Qt was that, up until recently, it was licensed under the LGPL and before that, it was under the restrictive 'Qt license'. This is no longer the case, so jump in!

      • Re:I wonder about this (Score:5, Interesting)

        by shutdown -p now ( 807394 ) on Saturday July 04, 2009 @08:16PM (#28583741) Journal

        You forgot one thing: performance. Qt guys take it very seriously, and have numerous tests showing off just how fast their rendering and layout code is. I would imagine that, for resource-constrained devices, this can be a big deal.

      • Re: (Score:3, Interesting)

        by Draek ( 916851 )

        My main issue is that Qt is pretty strongly tied to C++, and I *despise* that language. Whereas GTK in C may be horrible, but the bindings to Python, Ruby and C# are all excellent and a newbie dev could easily believe they were designed for them from day one.

        However, all the other advantages you mention are still valid, plus Nokia controls Qt so overall I support this move, it was the most logical thing they could do. They've lost me as a developer, but I don't think anyone's gonna cry over that ;)

        • Re:I wonder about this (Score:5, Informative)

          by abigor ( 540274 ) on Saturday July 04, 2009 @10:23PM (#28584189)

          Qt absolutely has bindings in other languages. For example, check out PyQt: http://www.riverbankcomputing.co.uk/news [riverbankcomputing.co.uk]

        • Re:I wonder about this (Score:5, Interesting)

          by Kjella ( 173770 ) on Saturday July 04, 2009 @10:43PM (#28584285) Homepage

          My main issue is that Qt is pretty strongly tied to C++, and I *despise* that language.

          Did you try C++ with or without Qt? I must admit, I don't like C++ outside of Qt, it brings the whole platform to another level. QStrings and QByteArrays are a godsend compared to std::string and char *. Using the QObject system I easily write applications with no memory leaks because it will delete any child QObjects when it goes, making it easy even without amy garbage collector. Finally, using signals and slots makes your application more robust - screw something up and nothing will happen because the signal never reaches its destination but it won't crash hard on an invalid pointer. Granted, I've heard you can do the same with STL and boost and duct tape, but I never managed to do it.

          • Re: (Score:2)

            by Aladrin ( 926209 )

            I quit writing C/C++ code years ago because of the insane amount of micromanagement I was having to do. Your post has about convinced me to give Qt a chance, though. Thank you.

            • I quit writing C/C++ code years ago because of the insane amount of micromanagement I was having to do. Your post has about convinced me to give Qt a chance, though. Thank you.

              The thing about C++ is that it is easy to back yourself into a corner. E.g, if you write "delete" anywhere, you are most likely doing something very wrong. Get past this, and it is a quite powerful and effective language, though I would love to have some legacy stuff cleaned up --- like the default conversions.

              • Re: (Score:2)

                by Roxton ( 73137 )

                E.g, if you write "delete" anywhere, you are most likely doing something very wrong.

                Can you point to any articles, framework sample code, or discussions of best practices that reflect the methodology you're describing?

                • Re: (Score:3, Informative)

                  by JudgeJackson ( 167835 )
                  The pattern is known as "Resource Acquisition is Initialization", or RAII. Search for that and you'll get a ton of hits. Simple rule of thumb: new in constructors, delete in destructors. There are smart pointer classes available to help you do this.Boost [boost.org] provides a set of them and it sounds like Qt has something similar.
          • The Qt designers don't just create widgets etc, they design components that are easy to program with. As part of this, they avoid stuff that requires the tricky/ugly parts of C++. For instance, you rarely need to explicitly delete objects, because their libraries use reference counting to automagically delete objects at the earliest appropriate time.

            So it is easy for any good programmer to learn enough C++ to use Qt effectively.

            (Actually, Qt uses an extended version of C++, implemented via a preproces

          • Re: (Score:2)

            by Draek ( 916851 )

            Without, and from reading a few Qt tutorials it seems that as long as you stay within it, it does make C++ programming much nicer and easier than 'pure' C++, so I'm gonna try writing a 'real' app in it now, thanks!

        • Re: (Score:2)

          by Klivian ( 850755 )
          My main issue is that Qt is pretty strongly tied to C++ This is repeated over and over again and even if people believe it, it' still not true. That is pure FUD. Whereas GTK in C may be horrible, but the bindings to Python, Ruby and C# are all excellent Fact is, the Qt bindings for those languages are more comprehensive and more up to date than the GTK counterparts. The Qt bindings all have powerful automatic tools for generating bindings for those languages, making it easy to keep up to date.

          • Re: (Score:2)

            by Draek ( 916851 )

            Fact is, the Qt bindings for those languages are more comprehensive and more up to date than the GTK counterparts.

            Do you have a source for that statement? because I've just tried PyQt again and, while its very nice and a far cry from the mess I tried ~3 years ago, so is PyGTK and I can't find any difference between either that doesn't come from the toolkits themselves rather than the bindings. And while I haven't tried Qt# yet, I have a hard time believing it could be better than Gtk# which is maintained by some of the people behind Gtk and Gnome themselves.

            • Re: (Score:3, Informative)

              by Klivian ( 850755 )

              Do you have a source for that statement?

              What about the PyGTK and GTK websites. According to the download links the latest stable and updated PyGTK are for GTK 2.14, and GTK 2.16 has been out since the middle of March. For PyQt you don't find many minor releases of Qt that has not been followed by a updated PyQt release inside a week or two, for the last 5 years or so.

              As for being comprehensive, the Qt bindings(at least PyQt) has a close to full coverage of the Qt classes. Last I checked PyGTK did not offer the same. And since Qt are not onl

      • Re:I wonder about this (Score:5, Informative)

        by StormReaver ( 59959 ) on Saturday July 04, 2009 @10:22PM (#28584183)

        > The main issue with Qt was that, up until recently, it was licensed under the LGPL....

        Slight correction: until recently, it was licensed under the GPL; but is now licensed under the LGPL.

      • Re: (Score:2, Informative)

        by Anonymous Coward

        GTK attempts to do object-oriented code in C and the result is a mess of explicit casting and macros.

        Take a look at GTKMM [wikipedia.org], the C++ binding for GTK+, which uses:

        • signal handlers with full C++ type safety (no macros)
        • the standard C++ library (including STL containers and iterators, unlike Qt)
        • object compositing
        • automatic memory management, including for dynamically created objects
        • internationalization with full UTF-8 support and C++ std::strings
        • C++ inheritance to define your own widgets
        • everything in nicely define

        • Re: (Score:3, Interesting)

          by ardor ( 673957 )

          gtkmm is sort of ok, but Qt is still superior. It has a much cleaner API, better documentation, a MUCH more powerful canvas widget, support for reflection of QObjects (very useful for stuff like RPC), etc.
          gtkmm on its own is fine, but it suffers from having to inherit the gtk wall bangers, most prominently, the API.

        • Re: (Score:2, Interesting)

          by Anonymous Coward

          Take a look at GTKMM [wikipedia.org], the C++ binding for GTK+, which uses:

          The problem is that gtkmm is always "something to take a look at" instead of being something people actually use. Why is that? The C mentality of gnome devels? General badness of gtkmm?

          One advantage of Qt is that it was C++ from birth, so C++ is the unquestioned first class citizen in the Qt world.

    • Re: (Score:2)

      by dbIII ( 701233 )
      There is a version of Qt for low memory devices (was called qtopia, now something else) which would give it an advantage on the platform instead of having to custom strip back the gimp toolkit. There's also the C vs C++ choice.

    • Re:I wonder about this (Score:4, Informative)

      by umeboshi ( 196301 ) on Saturday July 04, 2009 @07:52PM (#28583645)

      First, gtk+ is for C, while qt is for C++. Another major difference is that qt is more than just a widget toolkit, but an application runtime environment that provides widgets. This means that qt provides string handling, database connectivity, etc., although you don't have to use anything but the widgets and application objects, if you wish.

      I thing maemo is mostly written in C, so some parts will probably have to be rewritten in C++.

      This article may help a bit, although it only compares qt with gtkmm (the c++ bindings to gtk):
      http://www.telegraph-road.org/writings/why.html [telegraph-road.org]

      This article should be taken with a grain of salt, as it's pretty old, and may be inaccurate today.

      I started using gtk+ with python, way back in the 1.x versions. The 2.x bindings for python were much better, allowing me to write more pythonic code using gtk+.

      Later on, I decided to try out qt3, and I haven't looked back since. While it took a bit of getting used to, I found that it was easier to use qt, rather than gtk+, although I'm hard pressed to figure out exactly why.

      One of the things I liked about qt over gtk+ was the separation of the layout widgets and the interactive widgets. Coming from gtk, this was something that took me a while to understand, but once I got the hang of it, I liked it, and think that it's a better way to organize the widgets. With gtk, a vbox holds child widgets, such as buttons, labels, etc. So if you want to rearrange them in an hbox, you have to destroy those widgets and make new ones in the hbox. In qt, the layout widgets are of type "layout", and you can only have layout children in layout widgets. The interactive widgets are children of the main widget (or a child widget of the main widget). These widgets are "placed" into the layout, but can be removed without being destroyed, allowing you to rearrange the layout more easily.

      I also prefer the signal/slot mechanism in qt over the callback mechanism in gtk. On the average, it makes it easier to glue your widgets together, but there are a few circumstances where a callback mechanism is preferred, in which case you have to invent a new signal(s) and chain them together. This is because there is no order of slots called when a signal is emitted.

      Also, the qt documentation was better, more organized, and easier to read than the gtk docs (at least around the time I switched ~2004).

      Probably the largest reason why we're even having this discussion is due to licensing. Gtk gained a lot of popularity, due qt being licensed under the trolltech license, which restricted developers from using the free version in commercial products. The switch to gpl didn't do much to change this, although you could then create commercial products, but you also had to release the source for those products. So if you wanted to keep the source closed and use qt, you still had to purchase a commercial qt license.

    • Re:I wonder about this (Score:4, Informative)

      by Eil ( 82413 ) on Saturday July 04, 2009 @08:03PM (#28583687) Homepage Journal

      There is a lot of software for the Nokia N810 and below. Switching out to a new UI means a lot of stuff will either get uprooted or there will be a lot of libraries loaded into the machine's precious little memory.

      As it is, minor Maemo releases can (and sometimes do) break compatibility with applications while major releases are generally not expected to be backwards compatible at all. It works the same on any Linux distro or desktop environment. Development of Maemo has moved at a glacial pace, so when Nokia switches to Qt, I assure you it will be a major release.

      I'm looking forward to Maemo on Qt 4 if for no other reason than it will make WebKit support a cinch. (The current official Maemo web browser uses Gecko and using it is generally an unpleasant experience.) In fact, if I recall correctly, there are some KDE folks trying to get KDE 4 ported to Maemo, with all the interface enhancements necessary to make it usable on small-screen devices.

    • Nokia wants a common platform across their internet tablets and smart phones. Given that the Symbian is going to support Qt, and the Symbian user base is much greater, its makes sense that Maemo would want to have access to the 3rd party apps written for the user base that numbers in the millions

      And really it was clear in the talk he gave that the Maemo stack is still mostly unchange, and still using most of the Gnome libraries including crucial stuff like Tracker. Really even with the change in UI toolkit,

    • Re: (Score:2, Interesting)

      by drizek ( 1481461 )

      Unfortunately, the n8x0 development community has been kind of dead since the introduction of The Great One. It isn't completely gone of course, but it is a lot less active than it was a year ago. The current stable of apps aren't going to be as useful as we would like them to be. The other thing is that there never really was that many to begin with, nothing even approaching what the iPhone has. Most of the development seemed to revolve around fixing deficiencies wit hteh OS(alternate environments, media p

      • Re: (Score:3, Insightful)

        by mibus ( 26291 )

        Most of the development seemed to revolve around fixing deficiencies wit hteh OS(alternate environments, media players, web browsers and other things that got done right the first time in android/iphone/pre).

        Fully agree. Some of my most-used apps are competitors for built-in ones (Canola and MPlayer top the list, MaemoMapper, I also used Modest in competition with its built-in email some time ago).

        KDE devs who were never interested in writing gtk for the n800 may now get excited about the 900 and pick it up.

        ...and the existing pool of Gtk+ developers get frustrated after Yet Another API Change, and leave.

        There's never going to be the glut of third-party apps that the iPhone enjoys, when the API isn't stable - and you'd have much better luck again if you could keep the ABI stable for more than a year or two...

        I really lov

    • Can you name three apps that are available for Maemo that you would honestly miss?

      The mail app blows, the browser sucks, the media player is lousy, and the application manager is beta-quality, at best.

      Don't get me wrong, I love my n810, mostly for the hardware - Maemo is a drag.

      -

      Qt vs GTK: http://slashdot.org/askslashdot/01/11/21/0227206.shtml [slashdot.org]

      • Not three... but one -- the GPS mapping and routing app. But as someone else was describing how Qt covers a wide range of functions including SVG rendering, I think that perhaps such map software might be improved with a port from the existing Maemo to the future Maemo.

        Just about any other apps that follow, I'm sure, will be acceptable. It plays music. It plays video. It plays some simple games. It's a portable device. It does what I wanted it to do and I am sure under a new environment, it might well

    • Re: (Score:2)

      by jrumney ( 197329 )

      What are advantages of Qt over GTK?

      I'd imagine the fact that Nokia now owns it might have something to do with this move.

  • Qt != KDE, GTK+ != GNOME (Score:3, Informative)

    by Anonymous Coward on Saturday July 04, 2009 @06:51PM (#28583333)

    It seems like they're still planning on using a lot of GNOME components [vuntz.net], but putting a Qt skin on it. I just wonder if it is the best of both worlds, or the worst of both worlds...

    • Why would it be worse of both worlds? They're just libraries; mix and match however you like.

  • I can tell you right now, this will kill Maemo. QT is a pretty good GUI toolkit, but this is going to draw in QT Embedded (QWS server and such). I personally have been working on an Embedded QT device for 2 years and can tell you, QT Embedded is horrible. Nothing more then a Demo written by Trolltech to try and expand the market share. The biggest pain with QT, is that since it tries to be cross platform is it re-implements everything (Networking, Audio, Mutexs etc... etc..). They make it fairl

    • Re: (Score:2, Insightful)

      by ceallaigh ( 584362 )
      The real story is the Nokia / Intel announcement of cooperation on Atom/mobile products. Intel seems rather focused on Mobilin for MID with a long term strategy for handsets. While Nokia will be pushing their Ovi stores/maps/content with a new UI for Symbian. I doubt that Nokia ever looked on Maemo for more than an R&D effort. Commercially it was never a success nor a viable consumer product - a geek toy yes, a popular consumer product never. Maemo is irrelevant. The real thing to watch is the In

    • I can tell you right now, Maemo will not use Qt Embedded.

      'Bad code' is very subjective, and I would like you to prove Qt is slower than Gtk. Just because you say it's so, does not make it as such.

      One reason they are going with Qt, is because they bought Trolltech. They could not have that much control over gtkMM, however ancient and unmaintained that code is.

    • You seem to know what Maemo actually is. Since the summary doesn't care to enlighten us, could you maybe do the honors?

    • Re: (Score:2)

      by ardor ( 673957 )

      I have personally worked on QT embedded projects as well, for well over a year. Some platforms weren't supported out of the box, yet I didn't find it to be particularly painful. Neither was the signal/slot-system. I did use GTKmm before Qt though, and had to endure all the braindead API designs inherited from gtk.

    • The biggest pain with QT, is that since it tries to be cross platform is it re-implements everything (Networking, Audio, Mutexs etc... etc..). They make it fairly easy to use their bad, slow code, while the "beautiful" non-standard signal slot system makes it a pain to integrate with real C or C++ code.

      This "biggest pain" of yours is what makes it cross platform.

      You know what? You don't need to use these "slow" wrappers, you can use the file descriptors directly if you wish, and call to posix to your hearts content, if you don't care about running the code outside Linux. Good luck explaining that to your manager though.

      I invite to you to investigate how "slow" these wrappers are by just reading the code:

      http://tinyurl.com/loerlj

      They make it fairly easy to use their bad, slow code, while the "beautiful" non-standard signal slot system makes it a pain to integrate with real C or C++ code.

      PIBKCAP, probably.

    • Re: (Score:2)

      by ecki ( 115356 )

      ...this is going to draw in QT Embedded

      What makes you think this?

      ... their bad, slow code ...

      Care to shed some more light on this too?

  • Gtk+ is not Nokia's problem (Score:4, Interesting)

    by jipn4 ( 1367823 ) on Sunday July 05, 2009 @02:59AM (#28585045)

    Nokia has its own lightweight GUI library that they use with Symbian--and their UIs suck. They have built applications with Gtk+--and their UIs suck. They have build Windows and OS X desktop apps--and their UIs still suck. I think the problem Nokia has with GUIs and software has to do with how they develop software, not whether they use Gtk+ or Qt.

    Another problem with their choice is that it ties them to C++; the trend in mobile development, however, is towards other languages, like Javascript (Pre), Java (Android), Objective-C (iPhone), and C# (Windows Mobile). Only Symbian steadfastly clings to C and C++. That would be fine if Symbian actually ended up being the fastest and having the best UI of the bunch, but it's actually the slowest and least responsive of the bunch.

    • Re: (Score:3, Insightful)

      by ultrabot ( 200914 )

      Another problem with their choice is that it ties them to C++; the trend in mobile development, however, is towards other languages, like Javascript (Pre), Java (Android), Objective-C (iPhone), and C# (Windows Mobile).

      Actually, I think this will end up being a competitive advantage in the long run. If Nokia smartphones end up being the *only* smartphones that run (mostly) raw native code compiled straight for the metal, they will end up being the fastest in the long run, given equivalent hardware.

      That would be fine if Symbian actually ended up being the fastest and having the best UI of the bunch, but it's actually the slowest and least responsive of the bunch.

      The problem with Symbian isn't C++ - it's C++ done horribly wrong, and series of unfortunate technical choices (e.g. pervasive client-server architecture).

      • Re: (Score:2)

        by jipn4 ( 1367823 )

        Actually, I think this will end up being a competitive advantage in the long run. If Nokia smartphones end up being the *only* smartphones that run (mostly) raw native code compiled straight for the metal, they will end up being the fastest in the long run, given equivalent hardware.

        No, they won't. C++ is fast for small inner loops because programmers there can take full advantage of its features. Big applications end up being slow and bloated in C++ because programmers simply cannot manage the complexity

        • Re:Gtk+ is not Nokia's problem (Score:4, Insightful)

          by ultrabot ( 200914 ) on Sunday July 05, 2009 @04:26AM (#28585299)

          No, they won't. C++ is fast for small inner loops because programmers there can take full advantage of its features. Big applications end up being slow and bloated in C++ because programmers simply cannot manage the complexity anymore: all their time goes into chasing pointer bugs and dealing with include files, and little remains for performance tuning and algorithms.

          That's bollocks. C++ is not really that much less productive than Java/C# if you have a good platform toolkit to go with it (Qt). With Qt, you don't really manage your memory manually most of the time, the classes do it themselves through implicit sharing.

          Admittedly, C++ is much less productive than Python & other dynamic languages, but that's not the issue at table here; we are comparing against Java, C#, ObjC.

          And what is this "long run" you're speaking of anyway? If it takes 5 years for Nokia to optimize their current C++ applications, do you think anybody will care?

          The phone applications easily have a life span of several years. They get improved, but rarely rewritten.

          This applies even more so to "platform" level stuff. If you write more of that in C++ than Java, you'll have a faster platform, given equivalent algorithms.

          There is no "in the long run" for software; what counts is what you can deliver in 3-6 months, not in a few years.

          It seems Nokia was able to turn a profit with Symbian, even if Symbian is widely dreaded as the least productive programming environment in existence. I believe they will do great with Qt, and attract a great deal of third party interest as well.

          • Re: (Score:2)

            by jipn4 ( 1367823 )

            Admittedly, C++ is much less productive than Python & other dynamic languages, but that's not the issue at table here; we are comparing against Java, C#, ObjC.

            That is exactly the issue. Objective-C is a dynamic language, and the CLR and JVM support dynamic languages. Java is a lousy language, but even it has garbage collection, full RTTI, and reflection.

            This applies even more so to "platform" level stuff.

            Qt is an application and GUI toolkit.

            If you write more of that in C++ than Java, you'll have a fas

            • Qt is an application and GUI toolkit.

              No, it (QtCore part) can be used throughout the stack.

              But the "algorithms" aren't equivalent because the C++ programmer aren't even catching up with the level of functionality that users of better languages can implement in the same amount of time.

              Or so you would believe. Have you ever actually tried Qt? Or is all of this based on Java/C# propaganda you've read & bad C++ experience with crappy frameworks?

              Don't forget that things will only get better as the new C++ standard rolls in (we'll get lambdas, auto, ...).

              With Qt, Nokia is betting on the wrong horse. They should either switch to Android or buy Palm or do something entirely new.

              We'll see about that. I have to say my enthusiasm for Android waned the second I heard of Nokia buying Trolltech.

              • Re: (Score:2)

                by jipn4 ( 1367823 )

                No, it (QtCore part) can be used throughout the stack.

                You could use Perl "throughout the stack" if you worked hard enough at it; that doesn't make it a good idea.

                Or so you would believe. Have you ever actually tried Qt? Or is all of this based on Java/C# propaganda you've read & bad C++ experience with crappy frameworks?

                I've been programming in C++ for more than 20 years and in C for more than 25 years, as my primary languages. My dislike of those languages is based on intimate familiarity with it.

                Don'

                • I've been programming in C++ for more than 20 years and in C for more than 25 years, as my primary languages. My dislike of those languages is based on intimate familiarity with it.

                  I wasn't asking about C++, but about Qt - I developed a visceral dislike of C++ when doing Symbian development, even if it was not C++'s fault at all.

                  Although the new C++ standard fixes some things, it makes the basic problem with C++ worse--its complexity.

                  I have never been bitten by the complexity of the language. That problem is a bit overhyped.

                  OTOH, I have been bitten by crappy libraries (yes, that includes the standard library).

                  How is buying Trolltech going to fix the problem that Nokia's engineers apparently don't know how to organize a menu, organize a dialog, perform user testing, or perform bug tracking?

                  Subjective.

      • Re: (Score:2)

        by vakuona ( 788200 )

        Actually, I think this will end up being a competitive advantage in the long run. If Nokia smartphones end up being the *only* smartphones that run (mostly) raw native code compiled straight for the metal, they will end up being the fastest in the long run, given equivalent hardware.

        For that to be true, they would have to make sure their software was optimised for all different hardware they produce. If they are going to stick to one processor then maybe. But that is a lot of work for the developers, with the way current app stores work. Native code for applications is overrated. Users do not care about it. and oh, the long run absolutely does not matter.

  • Anybody with a hint of interest in the Maemo platform already knows this from Wikipedia and the project home page (at least 4 to 6 months)...

Slashdot Top Deals

No spitting on the Bus! Thank you, The Mgt.

Close