Slashdot Mirror

The reason Qt 4.4+ applications do not work with AutoIt, or any other WinSpy-like application, is the so-called "alien widgets":

http://labs.qt.nokia.com/2007/08/09/qt-invaded-by-aliens-the-end-of-all-flicker/

The normal behavior of an application is to create a Window object for every widget (window, button, combobox, etc) on screen. Usually that is done at the very low level, therefore most users (and even developers) do not know about it. This is true for every platform I know: Windows, X11 and Mac. I don't know the details about Wayland but I would be surprised if Wayland used a different approach.

The problem with the 1-window-per-widget approach is it causes a lot of unnecessary refreshes, which lead to flickering and a low performance over remote access protocols such as Remote Desktop, Citrix, etc. The reason is the graphics layer (GDI, X11, Quartz, etc) is responsible for refreshing the widgets and it will refresh the full widget even if only one pixel changed, or even if it didn't change at all and it was only the parent widget which changed.

Since version 4.4, Qt takes a new approach: create ONE (and only one) top level window for the application, then simulate all the other widgets by "drawing" them on screen. This allows the Qt painting system to have a finer-grained control over what needs to be repainted and translates into no flickering without the need for double-buffering.

Given that AutoIt is expecting full-fledged Window objects, it will fail with any application using Qt 4.4 because there is only ONE Window object.

Now that we know why AutoIt fails, we can try to find out what needs to be done.

The first approach is to just tell Qt to use native widgets, i. e. 1-window-per-widget. The Qt documentation, which you have not read, explains how to do this:

http://qt-project.org/doc/qt-4.8/qwidget.html#native-widgets-vs-alien-widgets

As you are very lazy, let me summarize that for you: set the QT_USE_NATIVE_WINDOWS environment variable to 1 and now you can use AutoIt. Performance will degrate a bit, though.

The proper approach, which needs to be implemented in AutoIt, would be to hook into the Qt painting system and "learn" about the internal representation of the emulated Window objects. That way AutoIt would be able to automate any Qt application, not matter if QT_USE_NATIVE_WINDOWS is used or not. This is what GUI testing automation tools such as TestComplete, Squish and others do: toolkit-specific plugins for Qt, Gtk, WPF, DevExpress, Telerik, etc.

That's of course only true for applications using QWidgets. For applications using Qt Quick, there is nothing like QT_USE_NATIVE_WINDOWS and the only possible approach is to create a toolkit-specific approach.

Nokia's Linux N9 has a front facing camera and an option for 64 (not 16) gigabytes. Plus the swipe keyboard is the bomb. Check out the video, 2nd thumbnail from the left, on the bottom of this page:

http://swipe.nokia.com/

It is a breeze for me to SSH to it, when I need a real keyboard, like to enter serious passwords, (hopefully rarely).

Those are the main advantages the Linux N9 has over the Lumia 900, its WP7 polycarbonite twin.

Nokia is irrelevant now as far as QT is concerned

Not entirely. Please correct me if I'm wrong, but Nokia still has fulltime QT devs on staff. And it looks like QT has pretty much landed on the N900, about the only Nokia product that actually has legs in spite of Elop's efforts to kill it.

I've had a Lumia 800 since november and the only two things I'm really missing now is a native app for Google+ (though the mobile web version works fine) and something that can talk to the OBD2 Bluetooth dongle I have for my car.

If you want a secure phone and want it to be from Nokia, then try the Nokia N9. It's a charm, in countries where it's available (yes for Australia, Finland, Italy, Sweden, etc. but not for USA, UK, Canada, Germany, Japan, etc.).

Moreover, Elop did his best to sink their flagship MeeGo device, the N9, by deliberately only selling it in low-income, low smartphone areas rather than the core markets you'd expect to place any device you actually want to succeed - and despite being made into a pariah, it outsells their entire Lumia (Windows) line 3 to 1. This is a device that that Nokia don't even list on their website as a product, but it still outsells all their Windows phones combined?

Uh, telling a little white lie on geography can get you to the N9 pages. It's not limited to low-income low-smartphone countries either, but it's certainly not listed for the largest markets (US, UK, Germany, etc.). However, it is shown for Sweden and Finland. Since you likely are not linguistically comfortable with either Swedish or Finnish, the Google translate versions are here and here respectively.

Moreover, Elop did his best to sink their flagship MeeGo device, the N9, by deliberately only selling it in low-income, low smartphone areas rather than the core markets you'd expect to place any device you actually want to succeed - and despite being made into a pariah, it outsells their entire Lumia (Windows) line 3 to 1. This is a device that that Nokia don't even list on their website as a product, but it still outsells all their Windows phones combined?

Uh, telling a little white lie on geography can get you to the N9 pages. It's not limited to low-income low-smartphone countries either, but it's certainly not listed for the largest markets (US, UK, Germany, etc.). However, it is shown for Sweden and Finland. Since you likely are not linguistically comfortable with either Swedish or Finnish, the Google translate versions are here and here respectively.

Moreover, Elop did his best to sink their flagship MeeGo device, the N9, by deliberately only selling it in low-income, low smartphone areas rather than the core markets you'd expect to place any device you actually want to succeed - and despite being made into a pariah, it outsells their entire Lumia (Windows) line 3 to 1. This is a device that that Nokia don't even list on their website as a product, but it still outsells all their Windows phones combined?

Uh, telling a little white lie on geography can get you to the N9 pages. It's not limited to low-income low-smartphone countries either, but it's certainly not listed for the largest markets (US, UK, Germany, etc.). However, it is shown for Sweden and Finland. Since you likely are not linguistically comfortable with either Swedish or Finnish, the Google translate versions are here and here respectively.

1. Continue on their own with Symbian/Meego/Maemo or whatever they develop in house and try to carve out a niche for a 4th (or 5th depending on how you count) OS in an already highly competitive market.

Given that they are really the only manufacturer making a serious play with Windows Phone, they were still in this position of trying to carve a market for a niche OS. It made no sense for them to abandon the traction they had already gained with their preceding developers models and return to shaky ground with a new, untested platform.

Moreover, Elop did his best to sink their flagship MeeGo device, the N9, by deliberately only selling it in low-income, low smartphone areas rather than the core markets you'd expect to place any device you actually want to succeed - and despite being made into a pariah, it outsells their entire Lumia (Windows) line 3 to 1. This is a device that that Nokia don't even list on their website as a product, but it still outsells all their Windows phones combined? I don't think Elop succeeded in his mission to make Linux phones look bad.

The bottom line is that despite taking his paycheck from Nokia, Stephen Elop appears to still work for Microsoft.

Most so-called dumb or feature phones allow you to install Java programs.

There's plenty of stuff you can do with the MIDP API:
http://www.developer.nokia.com/Develop/Series_40/

>Smart phones are more like computers that way; they're meant to have programs installed after you get it.
http://www.getjar.com/

People were installing Java apps before Apple even awoke to the concept.

So the question remains, what's a smartphone (other than the acid-wash jeans/Swatch of the 2000s)?

"Leave the market alone" implies long-term cause and effect. Nothing of note happens in the short term. The reason for government intervention is to cut out the number of people who suffer before revolting, and likewise to ensure that companies survive instead of shooting themselves in the foot.

It's good for both, but companies are so focused on short-term gains they don't see the long-term benefits of the government forcing them to stay viable.

And the CEO bit is way off topic. If you take any CEO and calculate the cost per unit that goes into their income, it is usually extremely low. They just happen to be in a high-volume business. I calculated the GM CEO to be making between $1 and $5 per car before the bailout, I don't remember exactly. Cutting his compensation to 0 would have affected car prices not at all. The whole C-suite would have saved $10 per vehicle.

Finally, the costs have nothing to do with the cost of providing. It's what people will pay. If it cost half as much to make an iPhone, it would sell for the same amount, because that's what enough people will pay. the only reason technology decreases in price is because the people who buy at that price have already bought. Reduce supply chain costs, reduce the price by a lot less than you save, and soon you have a high margin good that costs less but has a higher margin than when first released.

It takes time to educate people, for example, that text messaging is free to the carrier. The price has gone up instead of down, so consumers are losing that battle. But, with all of this throttling, I expect to see text messages completely free and tiered pricing for data usage. The SMS revenue stream goes away, but gets replaced by heavy data premiums. And it will work, because we are being conditioned that data costs money. In the long view, all of this will even out and we will be getting screwed by whatever the newest technology driver is. Because that's the one consumers know the least about.

Business regulation is the shortcut for consumer education. Note, I'm specifically not taking sides. Whether it is good or necessary depends on a lot of variables. But if consumers as a group understand the interplay between costs, profits, and regulation, they can usually either accept the screwing, or wait it out.

Before 3G speeds, it might have been plausible to run all data over SMS, assuming you had a gateway to use and embedded some sort of routing info. Now, although the option exists, very few people would find the response time acceptable. So they pay for 3G instead of unlimited texting. It's a choice, and most people opt for the high cost of convenience rather than undercutting the market. And, if SMS routing took off, you can bet the market would adapt, and then smart users would again react.

http://www.developer.nokia.com/Community/Wiki/Use_sms_as_data_bearer

Taking a lower resolution picture just resizes the image. To super sample with a fixed sensor array like in a camera, you'd need to take multiple pictures, either building one larger image and then sizing it down (hope you have a steady hand) or taking multiple pictures over time and laying those on top of each other (hope your subject doesn't move).

The "dedicated hardware" is just some piece of shit DSP that tries to voodoo away the noise. It's gaussian blur + unsharp mask on a chip.

Mmm. I read the white paper.

You know, the default output size is 5MP. What do you think happens when you size a fixed size 38MP (depending on the aspect ratio) to 5MP? Why yes, I believe you will have several samples for a single pixel. And guess what the dsp does. It voodoos away the noise by shrinking the image down from those (extra) samples. (The separate chip is needed because the processing power limitations of mobile chipsets (at least at the design time. I think this is about to change)).

Zooming by throwing some of the samples away is not ideal, but it does allow zooming without need to upscale the image, which is nice. Especially if you are taking a video.

Keep making fun of Nokia ignorant yankees. One of the main reasons Nokia is non-existent in US is because it tried to stand up to the telcos and protect consumer's rights by not crippling the phones as per the request of your greedy-ass cellular carriers. I guess it won't be making that mistake anymore.

The 808 just goes to show that some companies still employ engineers instead of designers. I mean, Apple has to rip off that patented technology from somewhere. ( http://www.zdnet.com/blog/btl/apple-pays-up-licenses-patents-from-nokia/50558 )

I'm not new here, so I know it's a lot to ask, but in addition to reading the fucking article, I encourage everyone to read the white paper too: http://europe.nokia.com/PRODUCT_METADATA_0/Products/Phones/8000-series/808/Nokia808PureView_Whitepaper.pdf

Also check out the sound quality of the 808 recording (listen with good headphones or speakers to really appreciate the difference) http://www.youtube.com/watch?feature=player_embedded&v=EbLFtF50y9A

And BTW, the summary is somewhat unfair. On the announcement they have posted (besides some impressive photo samples) a whitepaper were they clearly say that is not about quantity of megapixels, is about the quality you get when you average the results given by each one. I've also seen some of the videos were you get a very smooth digital zoom without loss of quality, and is quite remarkable.

Bleh, you're boring the appletards with technical details.

And BTW, the summary is somewhat unfair. On the announcement they have posted (besides some impressive photo samples) a whitepaper were they clearly say that is not about quantity of megapixels, is about the quality you get when you average the results given by each one. I've also seen some of the videos were you get a very smooth digital zoom without loss of quality, and is quite remarkable.

Bleh, you're boring the appletards with technical details.

Again, check out the whitepaper which explains how the pixels will be used:
http://europe.nokia.com/PRODUCT_METADATA_0/Products/Phones/8000-series/808/Nokia808PureView_Whitepaper.pdf

It is actual pixels. Have a look at the whitepaper on the technology. In essence, it can be used for digital zoom where you still have a decent resolution on the final image:
http://europe.nokia.com/PRODUCT_METADATA_0/Products/Phones/8000-series/808/Nokia808PureView_Whitepaper.pdf

Nokia understands it. They have a whitepaper on the technology which explains the use of the chip. Mainly, it is used for digital zooming.
Link to whitepaper: http://europe.nokia.com/PRODUCT_METADATA_0/Products/Phones/8000-series/808/Nokia808PureView_Whitepaper.pdf

Or perhaps the phone has been in development for some time, maybe it takes longer than Marketing announcement cycles to design and deliver new technology.

I can't find now the link (maybe it was on a video), but they say they have been developing this technology for four years.

And BTW, the summary is somewhat unfair. On the announcement they have posted (besides some impressive photo samples) a whitepaper were they clearly say that is not about quantity of megapixels, is about the quality you get when you average the results given by each one. I've also seen some of the videos were you get a very smooth digital zoom without loss of quality, and is quite remarkable.

Or perhaps the phone has been in development for some time, maybe it takes longer than Marketing announcement cycles to design and deliver new technology.

I can't find now the link (maybe it was on a video), but they say they have been developing this technology for four years.

And BTW, the summary is somewhat unfair. On the announcement they have posted (besides some impressive photo samples) a whitepaper were they clearly say that is not about quantity of megapixels, is about the quality you get when you average the results given by each one. I've also seen some of the videos were you get a very smooth digital zoom without loss of quality, and is quite remarkable.

well.. you would have api's. manufacturer specific at first, with manufacturer specific bugs. oh wait that's where html5&css apps on mobiles have been for years.
in this regard LG would be creating javascript api's to access those devices, just like samsung already did..

http://developer.bada.com/help_2.0/topic/com.osp.webapireference.help/symbols/WAC.Camera.html

for nokias I couldn't find a camera api off the bat(it might not exist, I don't remember seeing it anyhow), but this is where that would be anyways.. http://www.developer.nokia.com/Resources/Library/Web/#!web-apps/symbian-web-runtime/symbian-web-runtime-versions-and-device-support.html

oh and bada has sold in some relevant numbers.

but it's all shite really, web apps on mobiles... java makes much more sense and native apps of course even more. they're glorified web pages you're going to be looking at anyhow and things like phonegap already give you the possibility to do your stuff in html5 if you really insist..

Awesome post. :-)

However the newer versions of KDE4 are being based on Qt5, which has a base requirement of OpenGL (ES) 2.0 or above.

If I understood properly, the issue is that Qt5 will use an OpenGL rendering model. That doesn't mean that the graphics hardware requires an OpenGL working driver to function, because Qt5 can use a raster engine in the CPU, like does right now (passing "-graphicssystem raster", which is the default). Actually, they have given some numbers, and the CPU rasterizer is faster in Qt5, because LLVMpipe is faster than Qt's rasterizer.

That's really interesting, and it's good news. As long as Qt5 + KDE5 continue to allow machines to use it without requiring OpenGL 3D support in hardware, especially if there's still a software rendering (i.e. rasterizer) available, I'm happy. And I don't even need for it to be fast -- just that it will work. Thank you VERY much for pointing the above information out.

Remember also that Qt5 is not out yet, much less KDE5. It will take years for being forced to upgrade to KDE5. This year we will have a LTS release of Kubuntu, which means you will have supported KDE4 till April 2017. I think there will be also one or maybe even two Debian releases with KDE4.

That's good as a backup plan, although I'll doubt I'll need to resort to using it based on the technical details you've given me above. Debian has had KDE4 since the release of Squeeze two years ago. I've run Kubuntu in the past and ccasionally I retry Kubuntu (and Mint Debian) but haven't found any compelling reason to switch away from Debian, as Debian has full support for doing major upgrades without reinstallation. And as you probably know, Canonical recently announced that they were going to stop funding Kubuntu development after the April release of Kubuntu 12.04 and is also dropping commercial support for it.

      http://www.omgubuntu.co.uk/2012/02/canonical-withdraw-financial-support-from-kubuntu/
      http://www.h-online.com/open/news/item/Canonical-pulls-funding-from-Kubuntu-drops-commercial-support-1429603.html

However the newer versions of KDE4 are being based on Qt5, which has a base requirement of OpenGL (ES) 2.0 or above.

If I understood properly, the issue is that Qt5 will use an OpenGL rendering model. That doesn't mean that the graphics hardware requires an OpenGL working driver to function, because Qt5 can use a raster engine in the CPU, like does right now (passing "-graphicssystem raster", which is the default). Actually, they have given some numbers, and the CPU rasterizer is faster in Qt5, because LLVMpipe is faster than Qt's rasterizer.

Remember also that Qt5 is not out yet, much less KDE5. It will take years for being forced to upgrade to KDE5. This year we will have a LTS release of Kubuntu, which means you will have supported KDE4 till April 2017. I think there will be also one or maybe even two Debian releases with KDE4.

Still a shame those gui's became so bloathed and slooowwww. And thank God for fluxbox and the likes.

If this is how you feel, then you'd use Kwin with effects off, and wouldn't care about lack of OpenGL compositing. So I don't see your point.

Temporarily, right now, that works. However the newer versions of KDE4 are being based on Qt5, which has a base requirement of OpenGL (ES) 2.0 or above. http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/ This means presumably KDE4 will have the same base requirement. :-/

No need to switch. KDE will work fine, you just won't have all the fancy effects you may have become accustomed to.

Don't make that pronouncement so fast; Qt5 has a requrement for OpenGL (ES) 2.0 or above, and KDE4 is now being developed using Qt5.

http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/

The current "compilation requirements" are listed for KDE 4.4 but not for any version newer than that, but it is very likely that KDE4 will eventually have a baserequirement of OpenGL (ES) 2.0 due to that being a requirement for Qt5.

http://techbase.kde.org/Schedules

QML is really a breeze to write, and you can get very impressive visual effects easily. It has CSS-like transitions (but easier and with added benefits), and the property-system allows you to easily build complex relations between the visual elements. Objects are laid out using anchoring, where rather than defining x,y coordinates you just define the relations between the element. This also means that everything is out of the box adaptible to a wide array of screen sizes.

QML supports JavaScript inline and also the relations between the objects can be defined as JavaScript statements. Or, you can easily define methods to your QML objects by just writing out the JavaScript function in the code.

Extending from C++ has a small learning curve, but once you get into it there's nothing to stop you from doing your own components, or even implementing the whole visual element stack from the beginning. Not that you would really need to: the JavaScript is runtime compiled to machine code and executes so well that the interface is fast and responsive even on a smartphone.

LGPL is non-issue: it is both friendly to open source applications and fully proprietary closed source commercial applications, and places no legal constrains on your application code.

You can get started with QML right now. I dare you will be able to write your first app UI after 30 minutes.

I agree. I think that Qt is the best in class for UI development. And if you add Qt Quick to the mix, specially the new features coming in 2.0, is a clear winner if you need 3D added smoothly. Check out the video, is really cool: how you create any element, and apply GL shaders to create all sorts of effects on it, no mather is is a simple rectangle, or a fully fledged UI element.

Yes, I've owned mine for a month and concur. Check out the 2nd from the left thumbnailed-video at the very bottom of the page at http://swipe.nokia.com/ and dig on the one-handed GUI demo. Yes, the whole OS really is that smooth to use, and when the 1st service pack came out the Swipe keyboard became available too, (I swear Microsoft paid Nokia to BURY this OS & GUI).

The forums at maemo.org are very active with fanboys still modding their linux N900s and discussing things like installing Fennec (that's firefox mobile) to the N9 too. That's what I did and I am in phone browser heaven with the combo of n9 OS swipe gestures along with Firefox mobiles (which amazingly do not conflict, because the N9 swipe is 'from the edge in' while firefox works with a left swipe that did not start at the edge) So yeah, firefox tabs, bookmarks, etc.

I bought mine so I could reduce the wear and tear on my N900. Slashdotters enable Dev-mode in N9 settings, then VNC is right there ready to use over USB or wifi without a password (which you can tweak further) but this means you can use your regular PC keyboard to set passwords into the browser, etc.). Haven't got copy/paste to work over VNC in this way yet though, whereas normally that works for me.

To use a car analogy, I figure this thing is like knowing to buy a 1963 Corvette off the showroom floor new and just taking care of it. And the thing is just a solid little brick by the way, (but not big, svelte). Oh Nokia gives you a rubber skin kind of carrying case and I really like the grip it provides, so I guess ultra-svelte is not interesting for me. The OS with SSH, PGP keys, VNC etc. is just great.

The E7-00. If it doesn't come preloaded with Belle, then just wait for it to arrive in februari. If it's an old one; directly upgrade to Anna via software. After Belle it's over the air updates.

http://europe.nokia.com/find-products/devices/nokia-e7-00

"This should have been: The Headaches of Cross-Platform Development. It's not just a mobile thing. Today, if you're developing any kind of client-facing software then it's not just Android vs. iOS vs. WinPhone vs. BlackBerry."

True, but for desktops, cross-platform development is considerably easier, and is, in many ways a solved problem. I.e. Qt. However, for Android and iOS development, you have to deal with different programming languages for the UI.

For Windows Phone 7, this is even worse. On both iOS and Android you can at least develop a core engine in C++ and write native UIs in Objective-C on iOS and Java on Android. This is not possible with Windows Phone 7. In their infinite wisdom, MS decided that Silverlight and .NET/C# was your only alternative.

Given the absolutely minuscule market share that Windows Phone 7 has, the added effort may simply not be worth it.

http://blog.qt.nokia.com/2011/09/12/qt-project/
http://labs.qt.nokia.com/2011/10/21/the-qt-project-is-live/

http://blog.qt.nokia.com/2011/09/12/qt-project/
http://labs.qt.nokia.com/2011/10/21/the-qt-project-is-live/

Nokia's strong point (or given their performance lately, least weak point) is very much in their mobile phone business. If you look at their latest quarterly earnings, the net sale of mobile phones decreased (-14% from last) significantly less than their smart phones (-39% from last). On top of that, their smartphone sales dropped significantly in NA since last year, presumably because of the competition in the market and their lack of a real offering lately.

Furthermore, it's pretty clear (as in their only choice at the moment) that they will use Windows Phone as their only smartphone platform and are dropping any commitments to any alternatives they had on the shelf. There is a good chance they will make deep system changes in their ROMs to enhance the experience as well, further enveloping their relationship with them. I doubt they will commit to Android sometime down the line, since (a) Elop has obvious ties with MS and (b) it will be way more work for them to "Nokia"-ize the UI to make it appealing to people like every other manufacturer did.

So what if they sold that division to Microsoft? Their bread-and-butter won't change and won't be influenced by the move. Microsoft won't build any devices; if anything, they will have an easier hand in making sure the hardware gels perfectly with Windows Phone to make the experience as awesome as possible. Both companies would be better positioned to compete with Apple and Android since they will be able to use them as the "Nexus" of Windows Phone and, if they don't step on Nokia's toes, provide an awesome experience that neither company can match AND have manufacturer variety that gives people just enough choice to be appealing without being overwhelming. It's a win-win, though I'm probably being naive and overly simplistic.

I know the news is fake, but I'm really excited about this collaboration. I love Nokia and I think this will finally make them relevant again if they don't let Microsoft run the hardware design show too much. They already did the right thing by setting a tight hardware baseline; Nokia can handle the rest.

http://solarcharging.nokia.com/

Its for places with no charging infrastructure. Places where people have to pay to charge their phones.

The blog is here:
http://solarcharging.nokia.com/

There's region filter in extended search, and choice seems to be pretty poor.

Re: permissions, data connections are in "Network" permission group, "multimedia" and "connectivity" represent access to phone's camera/mic and serial/IR/bluetooth. Sucks to be an "untrusted developer" on T-Mobile. Also missing in both cases is Read/Write User Data, which includes not only PIM data, but also user file access.

There's region filter in extended search, and choice seems to be pretty poor.

Re: permissions, data connections are in "Network" permission group, "multimedia" and "connectivity" represent access to phone's camera/mic and serial/IR/bluetooth. Sucks to be an "untrusted developer" on T-Mobile. Also missing in both cases is Read/Write User Data, which includes not only PIM data, but also user file access.

I tried the first two links you gave, and on each page, inside "General", under "Regional Availability", neither included United States or North America. Nor did the "browsing through some specs" page let me filter by models available in my home market.

In the second link (6260 Slide specs), there was a link to Java API Access Permissions. From there, click MIDP 2.1 access rights. Based on what I've read in other comments to this story, "Ask always" means every time you do something, the operating system will put up a box asking whether you are sure you want to do something, a setting that cannot be saved from one session in the application to the next. Worse yet, both GSM carriers (AT&T and T-Mobile) appear to allow no "connectivity" or "multimedia" at all to "untrusted" (self-signed) applications.

I tried the first two links you gave, and on each page, inside "General", under "Regional Availability", neither included United States or North America. Nor did the "browsing through some specs" page let me filter by models available in my home market.

In the second link (6260 Slide specs), there was a link to Java API Access Permissions. From there, click MIDP 2.1 access rights. Based on what I've read in other comments to this story, "Ask always" means every time you do something, the operating system will put up a box asking whether you are sure you want to do something, a setting that cannot be saved from one session in the application to the next. Worse yet, both GSM carriers (AT&T and T-Mobile) appear to allow no "connectivity" or "multimedia" at all to "untrusted" (self-signed) applications.

I tried the first two links you gave, and on each page, inside "General", under "Regional Availability", neither included United States or North America. Nor did the "browsing through some specs" page let me filter by models available in my home market.

In the second link (6260 Slide specs), there was a link to Java API Access Permissions. From there, click MIDP 2.1 access rights. Based on what I've read in other comments to this story, "Ask always" means every time you do something, the operating system will put up a box asking whether you are sure you want to do something, a setting that cannot be saved from one session in the application to the next. Worse yet, both GSM carriers (AT&T and T-Mobile) appear to allow no "connectivity" or "multimedia" at all to "untrusted" (self-signed) applications.

I tried the first two links you gave, and on each page, inside "General", under "Regional Availability", neither included United States or North America. Nor did the "browsing through some specs" page let me filter by models available in my home market.

In the second link (6260 Slide specs), there was a link to Java API Access Permissions. From there, click MIDP 2.1 access rights. Based on what I've read in other comments to this story, "Ask always" means every time you do something, the operating system will put up a box asking whether you are sure you want to do something, a setting that cannot be saved from one session in the application to the next. Worse yet, both GSM carriers (AT&T and T-Mobile) appear to allow no "connectivity" or "multimedia" at all to "untrusted" (self-signed) applications.

It's hard to tell what's "representative", when Nokia feature phones range from something like this to something like this. You might try browsing through some specs.

At least all Nokia phones are comparatively low-pain for Java ME development (which is generally fucked up experience). Consistent API, installation by simply puttin .jar somewhere in the storage and opening it on the phone.

It's hard to tell what's "representative", when Nokia feature phones range from something like this to something like this. You might try browsing through some specs.

At least all Nokia phones are comparatively low-pain for Java ME development (which is generally fucked up experience). Consistent API, installation by simply puttin .jar somewhere in the storage and opening it on the phone.

It's hard to tell what's "representative", when Nokia feature phones range from something like this to something like this. You might try browsing through some specs.

At least all Nokia phones are comparatively low-pain for Java ME development (which is generally fucked up experience). Consistent API, installation by simply puttin .jar somewhere in the storage and opening it on the phone.

You guys need to take a good hard look at the file systems on those phones.

http://www.developer.nokia.com/Community/Wiki/Series_40_Filesystem

I don't understand your point. I could make a device that uses a simple filesystem capable of only using eight characters for the file name plus three characters as an extension to indicate file type. This doesn't mean the device uses DOS.

Not to mention that the apps available for s40 would make the phones more smart than feature. They had an RDP client. Calling Symbian a feature phone OS isn't accurate at all,...

I believe the distinction between a feature phone and a smart phone is its primary use. Feature phones have much smaller screens and often only have the familiar dial pad as its only input device. It is designed mainly for use as a phone with some nice informational apps available.

Smart phones tend to have a larger screen and a more sophisticated input device( qwerty keypad, touch screen, etc). It is designed mainly to run mobile applications and still perform as a phone. Notice the emphasis for apps over phone usage? I believe this is the only real difference between the two types of phones.

I also believe the term "Feature Phone" was a marketing term used by Nokia to differentiate themselves from Blackberry a very long time ago.

I could set up an old joke by stating that technically all phones are smart phones, since I could create a program that could run on it, and the only difference between a feature phone and a smart phone is $200.

...but might have something to do with Nokia running off to join the windows phone vendor ship.

Nokia has been using the term "Feature Phone" for as long as I can remember. Way before Microsoft was in a position to enter the phone market and enter into an agreement with Nokia.

PROTIP: Nokia Platform Services 2.0 JavaScript API reference.
Contains:
        nokia.device object
        Calendar API
        Camera API
        Communication Logs API
        Contacts API
        Landmarks API
        Location API
        Media Management API
        Messaging API
        Sensors API
        System Information API

There is something like this for every serious mobile OS.

Assuming there will soon be (or already is) WebGL in every such device... (And WebAL please? My old 5800 already had EAX4-like sound hardware and Java APIs.) ...you just have so idea what you are talking about.

(I have stopped working in the area when Nokia installed MS Suicide 2011 Elop Edition, so the above was easiest to find for me.)

Qt predates KDE by many years, and was originally delivered by Trolltech as a hybrid GPL/commercially licensed product before eventually being bought out by Nokia and released as fully LGPL open source when they opted to abandon the tiny revenue stream of Qt/Windows users who were paying for licenses in favour of wider adoption of the toolkit.

The dual license cash flow wasn't that tiny, when Nokia bought Qt in 2008 it was employing 250 people and AFAIK that was their only product. They even said it themselves on the developer FAQ:

As of Qt version 4.5, we license Qt under the LGPL version 2.1. Why? We have always chosen licenses that best support our goals. Following the Nokia acquisition, our goals have changed from being focused on revenue generation to supporting Nokias overall software strategy through the vision of Qt Everywhere.

As I understand it they wanted to put Qt on phones and make money on cuts from app sales, just like iPhone and Android. With that plan dead and buried, nobody has yet managed to give a sensible answer as to what Nokia hope to make money on using Qt. You get a lot of hand waving and buzzwords but no traceable cash flow of significance.

I was hoping that they might finally get a fix in for this bug (and the likes thereof), which has been making printing under KDE a pain in the butt for the last couple of years (the 4th most hated KDE bug out there) - but nobody seems to care, even tho a patch is available. Nice going with that community process... sigh.

Absolutely! Why did they abandon their Linux/QT development ship and Go Windows? Talk about terrible, terrible management. I couldn't agree with you more, and love my N900 so much I wanted to make certain to buy the last o' the Nokia linux phones (new) while I still could. For one thing, I know a flash media trick using the N900 I dare not publicize over the slashdots, which endear it to me so. And I'm still uncertain I can replicate this particular feat using the N9, but suspect an N9 UPnP work-around may be possible given further time and effort.

A big reason I bought the Heavy Duty (gorgeous) Solid Plastic N9 w/ Gorrila Glass is so I could keep the N900 (relatively) at home so it lasts forever as the wonderful client device that it is. I have not (yet) been able to fully encrypt the N900 as I do on all my other linux note/net-books

I am impressed by this series of N9 documents which encourages me to go mobile with It: http://conversations.nokia.com/2011/07/21/securing-the-nokia-n9

My N9 arrived from Switzerland and I think it is just freaking beautiful, and Microsoft really did a number on Nokia to muzzle this thing. Like:

The main website for the N9 is http://swipe.nokia.com/ Okay, so you're saying 'swipe, yeah I've heard of that. so what?' Man, if only Microsoft wasn't paying Nokia so hard to put a muzzle on it. Check out the videos at the bottom of that page, particularly the 2nd thumbnail'd from the left, at the very bottom. Dig on the one-handed swipe GUI. So now maybe you're thinking, 'well okay, if the one-handed GUI carries over through out the rest of the OS maybe...'

Okay, to do that, you have to wait for the Over the Air update (or use another way) to install the PR1.1, i.e. the first service pack for the OS since the phone was released. Then 'swipe' is fully installed, and you can also access control-keys, up/down arrows, etc. And it is freaking awesome! And being a linux guy of course I installed the devel extras which gets me the busybox terminal, and oh man what a gorgeous phone/client.

Today I was playing with the calendar and daily alarms; gorgeous! The included browser is fast and I'm a web-dev and really appreciate the perspective it brings to understanding modern mobile html5/touch browsers (that pops-up .flv videos in the media player but now .swf files).

I am certain Microsoft paid Nokia to *bury* the one-handed swipe GUI so deep as to obfuscate it completely. But I also think the Good Work of the Nokia linux team refuses to be buried so. At any rate, I give the N9 the coolest, most-positive thumbs-up review. And it does linux. (Oh, and who needs a million apps if I can bash script & ssh all over the place?)

You might want to take a look at: http://developer.qt.nokia.com/wiki/New_Signal_Slot_Syntax

syntax is ugly..

but it's not final. which begs the question.. actually this is the first "qt5 will be available on platform X" thing i've read..
isn't qt _already_ available on raspberry pi? reading their blog you would think so.