Slashdot Mirror

There is also Nokia's MeeGo-based linux phone, N9 which is really slick and has all the features you need, too. But support for that might be worse in the future, as Nokia is mostly going to do WP7 phones now.

I had a Nokia N900 but I bought an iPhone after a year or so. Although the N900 is still on par with the best smartphones out there hardware-wise, for me it was very annoying that there was hardly any new software coming out for it anymore. And I have a hole in my hand when it comes to smartphones. I bought a new one every year for the past 4 years.

PS. N9 does not have MeeGo in it. It has Harmattan. Harmattan and MeeGo are two different products and development branches. Harmattan were code name for Maemo 6.0 (5.0 is in N900) and MeeGo was project of Maemo 5.0 + Moblin. So do not talk about MeeGo when talking about N9 but only with Harmattan aka Maemo as that is used in it.

Better get on the horn and tell Nokia they're marketing their phone wrong.

The Nokia N9 smartphone, based on MeeGo 1.2 Harmattan
MeeGo 1.2 Harmattan: The Qt SDK now contains experimental toolchains and other experimental components to create MeeGo 1.2 Harmattan apps.
MeeGo Harmattan is a Linux-based software platform developed by Nokia for mobile devices.

PS. N9 does not have MeeGo in it. It has Harmattan. Harmattan and MeeGo are two different products and development branches. Harmattan were code name for Maemo 6.0 (5.0 is in N900) and MeeGo was project of Maemo 5.0 + Moblin. So do not talk about MeeGo when talking about N9 but only with Harmattan aka Maemo as that is used in it.

Better get on the horn and tell Nokia they're marketing their phone wrong.

The Nokia N9 smartphone, based on MeeGo 1.2 Harmattan
MeeGo 1.2 Harmattan: The Qt SDK now contains experimental toolchains and other experimental components to create MeeGo 1.2 Harmattan apps.
MeeGo Harmattan is a Linux-based software platform developed by Nokia for mobile devices.

PS. N9 does not have MeeGo in it. It has Harmattan. Harmattan and MeeGo are two different products and development branches. Harmattan were code name for Maemo 6.0 (5.0 is in N900) and MeeGo was project of Maemo 5.0 + Moblin. So do not talk about MeeGo when talking about N9 but only with Harmattan aka Maemo as that is used in it.

Better get on the horn and tell Nokia they're marketing their phone wrong.

The Nokia N9 smartphone, based on MeeGo 1.2 Harmattan
MeeGo 1.2 Harmattan: The Qt SDK now contains experimental toolchains and other experimental components to create MeeGo 1.2 Harmattan apps.
MeeGo Harmattan is a Linux-based software platform developed by Nokia for mobile devices.

And I'm serious. While not as versatile towards own-hosted solutions as the old Windows Mobiles, it's still light years beyond Android and iOS. You can easily use your own Exchange server to sync and share your contacts, calendar and other stuff, which gives you true privacy. It also doesn't leak data to Google like Android does, it doesn't have the malware problem that Android has and the phone itself is a full smart phone with an great UI (Windows Mobile somewhat started lacking in this in recent years).

The reason for this is simple too. Microsoft may be many things, but they have always respected privacy. In fact, they have never really cared about personal data the way Google does. All they want to do is sell you the software and be done with it. Google, on the other hand, gives you the software for free but then keeps tracking your every move. I rather choose the first one, but i guess it's everyone's own choice. I do value my privacy though.

The only time when you need contact with other servers is to download and install apps, which imo is a stupid decision fueled by iOS and Android doing it that way. Old Windows Mobiles always allowed you to install apps the way you wanted, the desktop Windows way. However, I guess that provides some extra security.

Nokia has also just unveiled Nokia Lumia 800, which looks really slick and has been praised by the people who have tested it. Personally I'm going to wait until it's released and read a few more user reviews, but I think that's going to be my next smart phone.

There is also Nokia's MeeGo-based linux phone, N9 which is really slick and has all the features you need, too. But support for that might be worse in the future, as Nokia is mostly going to do WP7 phones now.

Only because they HAD to. They made Webkit from opensource Konqueror (KDE) code

Open-source LGPLed Konqueror code, that being why they had to.

which ran on POSIX,

Try running it on an OS that implements POSIX and nothing else. :-) Perhaps the non-GUI calls it made were only POSIX calls, but it also made a ton of calls to Qt and KDE, which Apple had to redo.

to use in their new POSIX style OS.

"It runs on POSIXy OSes" probably wasn't a major reason for choosing KHTML; I think most of the open-source rendering engines available at the time ran on Linux etc..

Apple is making use of LLVM and Clang in their IDE for exactly the kinds of things talked about in the article, replacing custom parsers used for syntax highlighting or expression parsing in the debugger.

Nokia recently adopted Clang too for Qt Creator:

http://labs.qt.nokia.com/2011/10/19/qt-creator-and-clang/

The correct question is: intuitive for whom? Tens of thousands of web developers around the world seem to manage okay developing layouts in HTML/XHTML (you might argue that HTML isn't XML, but I would argue it's close enough that you won't find one intuitive and the other not). Is it intuitive for them? For many it is. Would it be intuitive for my grandmother? Certainly not. Remember that creating a layout in XML doesn't actually require writing XML - the Android plugin for Eclipse enables XML layouts to be created by drag-and-drop of GUI widgets, no XML editing necessary.

Gnome and other GUI frameworks have allowed layouts to be specified in XML for a long time, and there are other frameworks like QML that allow declarative descriptions of layouts in non-XML based languages. Is it the declarative nature of the task that makes it non-intuitive for you? Or is it the use of XML, rather than another declarative language like QML? There are many programmers who find declarative GUI layouts to be preferable to programatic ones, and there are many who are familiar with XML and prefer to use it rather than learn another custom layout language.

Of course, if you have a smartphone, you'll realise that most phone numbers aren't worth expending effort to remember, because your phone will do it for you. If a phone number is worth remembering, it's worth keeping in your phone's memory.

More like: if you have (just) a mobile phone - no need to go into smartphone territory, mobiles which won't do it for you are very rare for quite some time. Something like Nokia 1280 (or the new 100), among the least expensive phones at 20€ without contract, apparently has a phonebook for 500 entries (probably apart from the SIM card memory, the way this seems to usually work) - most likely way more than enough for vast majority of people. Even 50 entries (plus SIM card memory; here I'm sure, I borrowed this phone 5 years ago when my main one malfunctioned) of Nokia 1100 (just the most popular single consumer electronic device in the history of mankind) is probably enough for most.

At this point, I have a hard time understanding why anybody would want to remember phone numbers (apart from few essential ones of course - and even most of those would do fine as scribbles on a piece of paper, also carried around); unless it's a hobby or such.
And when utilising built-in notes, also such(^) phones can hold even more of the necessary numbers (at least of the "not secret" type, as most of them are)

Ultimately, the progress of our civilisation depends on, is largely about ever more efficient utilisation of prostheses for our minds - minds which have limited capacities, freeing them for new, upcoming pursuits and specialisations. The progress being largely about pushing old tools, habits, necessities, requirements, and skills of some bygone eras outside of the things we need to concern ourselves about. Many skills and activities which dominated the past become either obsolete or "hidden" from us.

First: I personally don't own any Apple products, thus your assertion is wrong.

In fact, here is a comment explaining why I HATE these types of phones, and here is a comment describing the phone that I do own. Yes, it's a simple old Nokia 6303c, with buttons, with camera taken out and with all phone unrelated functions turned off.

Thus I have just proven another AC to be wrong on his assertions. What an accomplishment.

Secondly: the wealth of new ideas that Jobs has generated are more than just the iPhones and iPads and iPods, all that.

He also produced the first computer animated movies, like Toy Story. He basically ensured that Pixar lives.

While you may be in a camp of hating Apple products, you cannot deny, that other products have borrowed extensively from Apple hardware and software solutions, as so many current gadgets look like they might have been created by Apple, and it's not a coincidence. So yes, by saying what you are saying, you are proving to be an idiot, which was my point.

Of-course I was not talking about that kind of idiot, I was more talking about this kind of idiot, but you are almost out there with them.

http://maps.nokia.com/

Note that this also only supports a limited set of browsers/OSes:

"
Check out the list of compatible browsers
Sorry, but for now, 3D Maps only supports the following browsers on Windows and Mac OS:
Internet Explorer 7+
Firefox 3.5+
Chrome
Safari 5+
"

and then there's Baidu which has a nifty model-based 3D view - I forget how to get that going now (something off www.baidu.com, probably), but it's quite impressive.

You mean "Qt for Embedded Linux and DirectFB"?

This means the three friends Linux-Nokia-Microsoft will be in bed together. It's not surprising considering Nokia already developed Qt and they were developing MeeGo which is based on Linux. Their Nokia N9 phone is quite awesome, actually.

Now what's great about this is the fact that with Nokia's history they have proven to put out quality hardware. They can also really use this to fight against both iPhone and what's worrisome for some, Android. Android has lots of fragmentation and patent related problems. Just yesterday it was revealed that Microsoft alone gets $400 million a day from Android.

What options does this leave for Qt-based development on embedded platforms?

Maemo on the N900 felt like the right direction with Nokia backing Qt, especially with projects like PySide created soley to offer a LGPL-licensed Python wrapper available to commercial developers (as opposed to PyQt). This permitted a single codebase to target desktop and mobile/tablet environments using a pleasant and completely open toolchain. MeeGo was set to carry on with Qt/X11.

But according to MeeGo's updated website, "We believe the future belongs to HTML5-based applications, outside of a relatively small percentage of apps, and we are firmly convinced that our investment needs to shift toward HTML5."

Considering that Microsoft owns Skype, in a few years down the road it's reasonable to expect that only GTalk and special features of GMail may still be missing.

Push notifications with end-to-end authentication is a goodie that Nokia could add; it is developing at least service-side support for unified push notifications.

You're looking for Nokia Situations.
Even if it's in beta it works as designed on my nokia E52, and I believe it works on any recently released Symbian phone (even the lower ends).

If that doesn't work for you, there are third party developed apps (Handy Profiles and Best profiles) that do the profile switch based on a calendar schedule or hour of the day.

Sad that few know that..

I doubt it. They devote an entire page to explaining why they don't use templates:

http://doc.qt.nokia.com/latest/templates.html

This is a pleasant surprise. I had understood that Nokia had become entirely dependent on Windows Phone and was setting itself up to be acquired as Microsoft's mobile unit, but then why would they need Qt when MFC/.NET is readily available?

It sounds like somebody decided that they need to keep their options open, which is smart:

At the end of June 2011, Marco Argenti, SVP, Nokia Developer Experience, confirmed that Nokia will âoemake Qt core to bringing applications to the next billion,â and he reassured developers that investments made in Qt today will live on in the future with Nokia. Adding the information about the 9M+ downloads per day on the Ovi Store, already today, provides a hint about the opportunity developers have with Nokia.

To mince the fine points with the submitter:

foundation whose only purpose is to host the infrastructure for the Qt project

There seems to be at least two things going on. The above statement is true:

I want to make it very clear that the foundation will not steer the project in any way. The foundation is in place only to cover the costs of hosting and run the infrastructure.

But this is also different:

All technical decisions, as well as decisions about the project direction, will be taken by the community of Contributors, Approvers and Maintainers. For example this means that people in Nokia working on Qt will start working with Qt as an upstream project. Everyone will be using the same infrastructure, including mailing lists and IRC ... but it may surprise you that that around 15% of the initial Maintainers do not work for Nokia. We also have quite a few Approvers from companies and the community. ...

The Qt governance, roadmap and releases will be driven openly by the Qt Project â" open to all the stakeholders willing to contribute. It will have an open governance model based on equal access to all discussions and tools, an open contribution process and meritocratic assignment of roles. We want Qt to excel by all measurements as a transparent, merit-based and participative open source community project. We believe this is the key to speeding up development and increasing the adoption of Qt.

Yet, they recognize the elephant in the room and are open about it:

As a last point I wanted to talk about one thing that is fixed for the project and not going to go away. To contribute to Qt, you will have to sign a Contribution License Agreement with Nokia. We have put a lot of effort keeping the Qt codebase legally clear and clean, and this attention to detail will continue under the Qt Project. We have been over the last months reviewed the CLA extensively with many stakeholders and believe we have a solution that is as inclusive as possible for all companies and individuals that want to contribute to Qt. The CLA also enables the commercial ecosystem around Qt to continue to thrive and contribute to the project. Further, there are a number of legal obligations from Trolltech and Nokia that have to be taken into account.

This license has a few problems any contributing entity is going to feel leery about. Just a few that jump out:

For the avoidance of doubt, Nokia has the right and no obligation whatsoever to utilize any Contribution and Nokia shall have the right, at its exclusive discretion, to include, suspend and/or exclude any Contribution from any release of Nokia Software Products.

I can see why Nokia wants to not imply they'll maintain a useless patchset forever, but they also have a potential strategic weapon against competitors here.

The seat, or legal place, of arbitration shall be Helsinki, Finland.

This is a pleasant surprise. I had understood that Nokia had become entirely dependent on Windows Phone and was setting itself up to be acquired as Microsoft's mobile unit, but then why would they need Qt when MFC/.NET is readily available?

It sounds like somebody decided that they need to keep their options open, which is smart:

At the end of June 2011, Marco Argenti, SVP, Nokia Developer Experience, confirmed that Nokia will âoemake Qt core to bringing applications to the next billion,â and he reassured developers that investments made in Qt today will live on in the future with Nokia. Adding the information about the 9M+ downloads per day on the Ovi Store, already today, provides a hint about the opportunity developers have with Nokia.

To mince the fine points with the submitter:

foundation whose only purpose is to host the infrastructure for the Qt project

There seems to be at least two things going on. The above statement is true:

I want to make it very clear that the foundation will not steer the project in any way. The foundation is in place only to cover the costs of hosting and run the infrastructure.

But this is also different:

All technical decisions, as well as decisions about the project direction, will be taken by the community of Contributors, Approvers and Maintainers. For example this means that people in Nokia working on Qt will start working with Qt as an upstream project. Everyone will be using the same infrastructure, including mailing lists and IRC ... but it may surprise you that that around 15% of the initial Maintainers do not work for Nokia. We also have quite a few Approvers from companies and the community. ...

The Qt governance, roadmap and releases will be driven openly by the Qt Project â" open to all the stakeholders willing to contribute. It will have an open governance model based on equal access to all discussions and tools, an open contribution process and meritocratic assignment of roles. We want Qt to excel by all measurements as a transparent, merit-based and participative open source community project. We believe this is the key to speeding up development and increasing the adoption of Qt.

Yet, they recognize the elephant in the room and are open about it:

As a last point I wanted to talk about one thing that is fixed for the project and not going to go away. To contribute to Qt, you will have to sign a Contribution License Agreement with Nokia. We have put a lot of effort keeping the Qt codebase legally clear and clean, and this attention to detail will continue under the Qt Project. We have been over the last months reviewed the CLA extensively with many stakeholders and believe we have a solution that is as inclusive as possible for all companies and individuals that want to contribute to Qt. The CLA also enables the commercial ecosystem around Qt to continue to thrive and contribute to the project. Further, there are a number of legal obligations from Trolltech and Nokia that have to be taken into account.

This license has a few problems any contributing entity is going to feel leery about. Just a few that jump out:

For the avoidance of doubt, Nokia has the right and no obligation whatsoever to utilize any Contribution and Nokia shall have the right, at its exclusive discretion, to include, suspend and/or exclude any Contribution from any release of Nokia Software Products.

I can see why Nokia wants to not imply they'll maintain a useless patchset forever, but they also have a potential strategic weapon against competitors here.

The seat, or legal place, of arbitration shall be Helsinki, Finland.

http://press.nokia.com/1997/07/31/nokia-provides-narrowband-sockets-server-implementation/

"Narrowband Sockets defines an efficient implementation of User Datagram Protocol (UDP) using store and forward services over wireless messaging networks."

Failed horribly of course. I know cause I once built an agent to send push email to phones with it. Worked pretty well with my old Nokia 9110. I should have called it blackberry and built a big company around it ;)
 

For C++ I would suggest Qt.
For C I would suggest Minix3.

Qt is probably one of the WORST choices for C++ you can possibly suggest because it has NON-STANDARD "moc" (Qt ONLY) phase to it which is NOT C++ ! Neither are Qt "signals" and "slots" which rely on Qt "moc"! Boy oh boy talk about "bad advice"!

The more lines of code the more difficult to get started as a general rule. Just find a small library that provides support for something you have an interest in. Tinker with it.

Like Qt.
See, that's the smallest - only two letters :)

Seriously, Qt Creator is an IDE that may make me switch from C# to C++. It is fast, runs on almost every platform, and is available under LGPL so it's possible to develop both open and closed source projects that use it.

For C++ I would suggest Qt.
For C I would suggest Minix3.

Apart from sample gadget apps I have yet to see the appeal. I haven't seen a single native looking QML app for PC yet, the controls for doing so aren't even done yet, so how are they supposed to replace UI files? Also Nokia has clearly stated that C++ interfaces to the new features in QML are not a priority so it is pretty obvious that Qt is indeed loosing its C++ roots. With ui files you could do everything they did by hand. QML won't allow that anytime sone (possibly never if you read the nokia blogs).

Seems like they read Slashdot or something: Native looking QML.

You will see native applications using QML way before you see QWidgets dropped.

You misunderstand how QML is supposed to be used. It's nothing at all like building a web app. Its biggest problem right now is that there aren't any good books about how to use it correctly, and what your overall design philosophy should be.

If we are to stay with the web analogy, in terms of usefulness QML/C++ is to plain C++ like CSS/HTML is to plain HTML. Positioning, reacting to changes, tasteful animations etc. are all extremely simple in a declarative UI. Explaining how to use it would be too much for one post, but it's becoming so powerful you'll soon be able to manipulate your UI using shaders. I've added comments to explain the basic QML, but the original article is here.

Image { // Create a new image object
width: 180
height: 180
source: "winter.jpg"

Text { // Create a new text object parented to the image object
id: theItem // Give this object an id to refer to
anchors.fill: parent // Automatically and constantly adjust to the size of the parent
horizontalAlignment: Text.AlignHCenter
verticalAlignment: Text.AlignVCenter
font.pixelSize: 120
font.family: "Times"
color: "blue"
text: "Qt"
}

ShaderEffectItem { // Create a new ShaderEffectItem object
anchors.fill: parent // Automatically and constantly adjust to the size of the parent

property variant source: ShaderEffectSource {
sourceItem: theItem // The object that the shader will draw
smooth: true
hideSource: true
}

property real amplitude: 0.02 // Define new variables for the shader to interact with.
property real frequency: 20
property real time: 0
NumberAnimation on time { loops: Animation.Infinite; from: 0; to: Math.PI * 2; duration: 600 } // Animate the time variable. You can also make animations that automatically animate objects' size changes when you do, say, width = 300.
fragmentShader: " // Embedded fragment shader code
uniform highp float amplitude;
uniform highp float frequency;
uniform highp float time;
uniform sampler2D source;

None are officially supported, but there has been work done to support at least Android and iOS. I think the lack of a WP7 port is more Elop running the company into a ground crap (I mean, if you could write a Qt app for Symbian or Meego and port it to the new Microsoft-Nokia devices...) so that may be rectified. Personally I think WP7 is doomed within a few years, and iOS not too long after that (be warned, I am also a Free Software nut so ...).

Straight from their own mouth

* Nokia will help drive and define the future of Windows Phone.
* Nokia and Microsoft will closely collaborate on development, joint marketing initiatives and a shared development roadmap

They are both in bed with a hardware manufacturer now, have both claimed it won't affect other licenses of the OS, and both have something to loose if they alienate the other OEMs.

Conspicuous by their absence from list of supported platforms are all currently popular smartphone and tablet platforms in the United States: iOS, Android, and Windows Phone 7.

There are other ways than rewriting the same thing several times. You don't even have to use C or C++. You already need at least different layouts for desktops, tablets (really just desktops without the input devices), and phones (or: tiny screen devices) for an application to be usable. So what is the advantage of using an overgrown design-by-committee hack that has repeatedly rejected all innovation in the name of compatibility? It doesn't help that HTML5 is probably more difficult to implement than the entire rest of an operating system.

Qt 5 will be binary incompatible with Qt 4

Not quite, at least as far as I understand it. See this for example: https://bugreports.qt.nokia.com/browse/QTBUG-397. There are more planned changes that break ABI.
Qt only guarantees ABI compatibility between point (e.g. 4.6.1 to 4.6.2) releases; they sometimes manage to retain ABI between minor (e.g. 4.6 to 4.7) releases, you can read about it somewhere in the docs.

I am reminded of this :

"Text Rendering in the QML Scene Graph"

http://labs.qt.nokia.com/2011/07/15/text-rendering-in-the-qml-scene-graph/

"Some time ago, Gunnar presented to you what the new QML Scene Graph is all about. As mentioned in that article, one of the new features is a new technique for text rendering based on distance field alpha testing. This technique allows us to leverage all the power of OpenGL and have text like we never had before in Qt: scalable, sub-pixel positioned and sub-pixel antialiased and at almost no cost."

Largely incorrect.

QML is like CSS, with inline JS, and Qt's API expressed as JS bindings.

True some advanced things still need C++, but you can make QML component objects from and use them in larger projects as a "custom control". Also there is the database API. The global object holds some misc properties.

People can and do whole app is in QML. And the advanced stuff from Qt Mobility - GPS, etc comes with JS/QML bindings.

Largely incorrect.

QML is like CSS, with inline JS, and Qt's API expressed as JS bindings.

True some advanced things still need C++, but you can make QML component objects from and use them in larger projects as a "custom control". Also there is the database API. The global object holds some misc properties.

People can and do whole app is in QML. And the advanced stuff from Qt Mobility - GPS, etc comes with JS/QML bindings.

Largely incorrect.

QML is like CSS, with inline JS, and Qt's API expressed as JS bindings.

True some advanced things still need C++, but you can make QML component objects from and use them in larger projects as a "custom control". Also there is the database API. The global object holds some misc properties.

People can and do whole app is in QML. And the advanced stuff from Qt Mobility - GPS, etc comes with JS/QML bindings.

I would. But what's the Android counterpart to an iPod touch?

An option might be to use Nokia's upcoming N9 Linux phone, with Android running in a virtual machine when you really want it. The phone is supposed to come with Alien Dalvik installed (an Android VM compatibility layer). Available in a single solid block of black, blue, or pink polycarbonite with curved Gorilla glass and no buttons on the face.

What kinda excites me as a developer, besides it being linux and an upgrade to my N900 and all that, is the GUI is worked out for single-handed usage.

http://www.slashgear.com/nokia-n9-android-app-support-promised-with-alien-dalvik-22160809/
http://swipe.nokia.com/

In the U.S. the Amazon.com store seems to be the best place I've seen so far to buy such unlocked phones.

Take a look at ticket #1 on the Nokia OpenCL plugin. Arbitrary code execution anyone? The security issues with WebGL are massively overblown, but WebCL seems to be a different matter entirely.

Nokia has been working on this since at least 2009, just search for their Kamppi trial. I know that it's fashionable to knock Nokia on many things, but they do (or is it did?) work on some very fore-front things.

Somebody else created a similar application for his Nokia phones:
http://www.techalps.com/nokia/any-minnesota-readers-please-give-this-mall-of-america-app-a-try.html

I know, I know. Have you had a look at Qt? It compares quite favorably.

Seems they don't have any data on the Nokia N900. That's OK; We can get it off of Nokia's web page :

"The highest SAR value under the ICNIRP guidelines for use of the device at the ear is 0.80 W/kg."

Not bad at all, especially compared to the HTC Nexus One or the Motorola Droid Pro at 1.39 W/kg .

jdb2

What a curious selection of phones. The venerable Nokia 3410 is missing, but they somehow bothered to test an N-Gage.

Here is comprehensive data for Nokia handsets.

Thanks for the tasty FUD!

Some comments here claim Qt is not dying because Nokia made some announcement and the Qt blog is hyperactive.

But look at the facts:
-the IRC channel they used: #qt-labs, has almost no activity since February

Looks like there's quite a bit of activity from just the last week

-the brand new Qt Developer Network has been deserted by the trolls

It'd be great if things were deserted by the trolls, I guess... Anyway, it doesn't seem deserted by the users

-the blog posts on Qt labs are just about future project, never anything concrete for the current library

Of the five posts on the front page, two are about merges of experimental features (the QML scenegraph and Lighthouse), two about conferences and summits, and one's about the release of QtWebkit 2.1.1. Not current enough for you?

-the plans for Qt 5 announced recently are ridiculous, no troll was involved in those

I'm not even going to reply to that one!

-the development on qt.gitorious.org stalled since February

If there is not quickly a fork of Qt, we will discover in 2 years that Qt is outdated and there is no longer any professional GUI library for Linux.

Latest commit is dated Jun 1 2011

Now, WTF are you talking about again?

Thanks for the tasty FUD!

Some comments here claim Qt is not dying because Nokia made some announcement and the Qt blog is hyperactive.

But look at the facts:
-the IRC channel they used: #qt-labs, has almost no activity since February

Looks like there's quite a bit of activity from just the last week

-the brand new Qt Developer Network has been deserted by the trolls

It'd be great if things were deserted by the trolls, I guess... Anyway, it doesn't seem deserted by the users

-the blog posts on Qt labs are just about future project, never anything concrete for the current library

Of the five posts on the front page, two are about merges of experimental features (the QML scenegraph and Lighthouse), two about conferences and summits, and one's about the release of QtWebkit 2.1.1. Not current enough for you?

-the plans for Qt 5 announced recently are ridiculous, no troll was involved in those

I'm not even going to reply to that one!

-the development on qt.gitorious.org stalled since February

If there is not quickly a fork of Qt, we will discover in 2 years that Qt is outdated and there is no longer any professional GUI library for Linux.

Latest commit is dated Jun 1 2011

Now, WTF are you talking about again?

Exactly, just a quick look at the dev blog shows the following updates with respect to new features (some stable releases, some tech preview):

• QML Scene Graph in master branch
• Qt Webkit minor releas
• Qt 4.8 tech preview
• Updates on Qt Creator, and its integration on the SDK
• Updates on the open governance
• Qt Quick 3D
• Qt Mobility 1.2
• First plans for Qt 5

This is only during May. If anything, I see Qt more alive than ever.

There is also the misconception that only the Qt developers do interesting research and add features. That's very wrong. Lots of KDE ideas were implemented in Qt at one point or another. Also note that companies like Digia or ICS (and several others) are now way more involved in Qt than ever, and will be more once the open governance transition finishes.

...QT continues developing announcing cool features, like the QML scene graph (post from today)

And in 2011, Linux still has such fundamental issues such as Ctrl-V and RightClick+Paste not giving the same result.

For KDE terminal apps, it's [Shift]+[Ins], which is easy enough to find out from the context menus.

  Or such ridiculous things like when you have copied something to the clipboard, it disappears if you quit before pasting. It was probably written down in some POSIX standard 40 years ago that this should forever be absurd, and so no amount of sanity can prevail.

Agreed, this "clear the *system* clipboard when shutting down any app" behaviour is beyond stupid.

Go ahead and enjoy your Windows 7. It's not so bad, really -- first decent thing to come out of the MS OS mill since Win2K. Just always remember that Microsoft don't consider it "your" computer, and you'll be just fine.

You were deprived of a proper desktop as a child. You know nothing of multiple workspaces, the ability of your applications to share their data with each other, even the simplest things like changing the color of your window decorations is beyond your ken. It's like you were raised in a cage.

And in 2011, Linux still has such fundamental issues such as Ctrl-V and RightClick+Paste not giving the same result. Or such ridiculous things like when you have copied something to the clipboard, it disappears if you quit before pasting. It was probably written down in some POSIX standard 40 years ago that this should forever be absurd, and so no amount of sanity can prevail.

"foo n-1 was the best thing ever, new is crap, Windows 7 is shiny." Okay then. Use Windows 7.

I do. Three and a half years of struggling with Linux was enough, thank you.

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.

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.

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.

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.