Category Archives: qt

Google Native Client: browser apps unleashed, or misconceived and likely to fail?

Last week Google integrated Native Client into the beta of Chrome 14. Native client lets you compile C/C++ code to run in the browser. It depends on a new plug-in API called Pepper. These are open source projects sponsored by Google and implemented in the Chrome browser, and therefore also likely to turn up in Chrome OS which is an operating system in which all apps run in the browser.

Native Client is cool. For example, NaCLBox lets you run old DOS games in the browser by porting DOSBox to Native Client.


Another project is Qt for Google Native Client, a project currently in development. Qt is an excellent and popular GUI and application framework which would speed development of Native Client apps as well as enabling many existing applications to be ported.

It is also worth mentioning that Native Client provides another way to run .NET code in the browser, via Mono with NaCl support.

Why Native Client? Google’s vision, or at least the part of it that focuses on Chrome OS rather than Android, is that everything runs on the Internet and in the browser, making the local operating system unimportant and easily replaced. Native Client removes any performance compromises in managed languages such as JavaScript, ActionScript or Java, as well as easing migration for businesses with existing C/C++ code.

Writing native code for the browser is nothing new. Both Microsoft’s ActiveX and the NPAPI plug-in API used by non-Microsoft browsers let you extend the browser with native code. However Native Client is seamless for the user; you do not have to install any additional plug-in. The main limitation is that Native Client applets do not have access to the local operating system, for security reasons.

It is also worth noting that Native Client apps are not altogether cross-platform. They must be recompiled for different CPU instruction sets, with the current implementation supporting x86 and ARM though you have to compile two binaries. Google says it will support LLVM output to enable cross-platform binaries though this will impact performance.

But is Native Client secure? That is an open question. Google was aware of the security challenge from the beginning of the project. Unlike the plug-in mechanisms which rely mainly on trust in developer competence and signed code to verify the origin of the plug-in or ActiveX control, Native Client inspects the actual code for unsafe instructions before allowing it to run. There is also an “outer sandbox” which intercepts system calls.

However, adding any new way for code to run makes the browser less secure. Google ran a Native Client Security Contest to help identify vulnerabilities, and the contestants did not have any problem finding security flaws. Of course all of these discovered flaws will have been fixed, but there may be others and likely will be.

And is Native Client necessary? The latest JIT-compiled JavaScript engines are fast enough to enable most types of application to run at a satisfactory speed. This is not just about performance though; it is about reusing existing skills, libraries and applications. There is no doubt that Native Client is nice to have; whether its benefits outweigh the risks is harder to judge.

The last question, which may prove the most significant, is political. Google has forged ahead on its own with Native Client, saying as vendors always do that it hopes it will become a web standard. In the early days of the project, it looked like a Native Client plug-in might enable the feature in other browsers, but abandoning NPAPI for Pepper makes this difficult. Will other browser vendors support Native Client?

Here is a comment from Google’s Ian NI-Lewis that I find remarkable:

As you probably know, the rule in Web standards is "implementation wins." So we’re concentrating on getting a good quality implementation out the door. We’re doing that in Chrome. That doesn’t mean that NaCl is intended to be "Chrome only," just that we have to start somewhere.

So Native Client is non-standard, and therefore less interesting than HTML 5 until either Google has a Microsoft-Office-like de facto monopoly of web browsers, or it persuades Mozilla, Microsoft and Apple to support it.

That said, you can think of Chrome as an installable runtime in the same way as the Java Virtual Machine or Adobe Flash, just a potentially more intrusive one. Here is our app, you have to install the free Chrome browser to use it. If this happens to any great extent, I can foresee other browser makers hastening to support it.

Nokia’s Elop fears mobile duopoly, but it is already here

It is day two of Mobile World Congress here in Barcelona; and everyone is pondering the implications of Nokia’s Windows Phone partnership with Microsoft. It is a pivotal moment for the industry, but not necessarily in the sense that the two partners hope.

Let me state the obvious for a moment. This is not good for Nokia, though it might be “the least bad of all the poor choices facing Nokia”, as Mikael Hed of Rovio (Angry Birds) put it yesterday. Nokia has huge market share, but it was already falling sharply, as these figures from late last year illustrate. Nokia’s total market share declined from 36.7% in Q3 2009 to 28.2% in Q3 2010; and its Smartphone (Symbian) share from 44.6% to 36.6%. These are still big numbers, but will inevitably decline further.

Following last week’s announcement, though, Nokia will transition from a company which formerly commanded its own destiny with Symbian, to one that is an OEM for Microsoft. The savings will be substantial, as CEO Stephen Elop noted at the press event here on Sunday evening, but it is a lesser role.

Why has Nokia turned to Microsoft? It is not a matter of Microsoft planting its own man in Nokia in a desperate effort to win market share. On Sunday Elop said he was no trojan horse, and also laid to rest rumours that he is conflicted thanks to a large Microsoft shareholding; he is selling as fast as the law allows, he said, and his shareholding was nowhere close to what was alleged in any case.

Rather, the Nokia board brought Elop in specifically to make tough decisions and likely form an alliance with either Google or Microsoft. I am not sure that former Nokia exec Tomi Ahonen is the best source of commentary – he is unremittingly negative about the alliance – but I like his piece on the choices facing the board last year, when it must have decided that MeeGo, the mobile Linux co-sponsored by Intel, could not deliver what was needed.

Elop chose Microsoft, his argument being that the choice was between Android and Windows, and that going Android would have created a duopoly that was good for Google but bad for the industry. By going Windows Phone “we have created a three horse race,” he said.

It is a fair point as far as it goes – though maybe he takes too little account of RIM, especially in the enterprise market – but whether Nokia can really break that duopoly is an open question. It is not a question of how the duopoly can be avoided: it already exists.


Given the absence of Apple, this Mobile World Congress could almost be called the Android World Congress, such is the dominance of Google’s mobile OS. It works, it is well-known, it is freely customisable by manufacturers and operators. Android is not perfect, but it is a de facto standard which nicely meets the needs of the non-Apple mobile industry.

This morning three significant far Eastern manufacturers announced new Android devices; none announced Windows Phone devices. The three are HTC, Alcatel Onetouch (which claims to be the fastest-growing handset provider in the world), and Huawei. At the Alcatel Onetouch press conference I asked CEO George Guo why his company was focused on Android:

Why Android? Android is a phenomena. It is what every operator wants and also what the consumer is looking for. The iPhone is great but just has one type, and also it is highly priced. People want something different so are looking for variety. Android-based phones provide that opportunity. With Android phones you can range from $100 up to several hundred. Also we can make customisations based on the Android system. We can fit different kinds of customers’ needs. That’s why, from the whole ecosystem point of view, because recently (laughs) people talk about this a lot, we think that Android does provide quite an ecosystem.

Note how Guo (unprompted) makes reference both to the other member of the duopoly, Apple, and the new pretender, Microsoft/Nokia.

However good their products, rivals such as RIM with its new QNX-based OS and HP with WebOS will struggle to compete for developer and public attention.

Does Windows Phone have better chances? If Nokia could easily translate its Symbian sales last year to Windows Phone sales next year, then sure, but that would take a miracle that beleaguered Nokia is unlikely to deliver. Windows Phone 7, launched last year, demonstrates that despite its desktop dominance Microsoft cannot easily win mobile market share, and that partners such as HTC, Samsung and LG are focused elsewhere. Nokia’s commitment will greatly boost Microsoft’s market share in mobile, but to what percentage is frankly hard to guess.

There are a couple of other unanswered questions. One is about differentiation. In order to compete with Apple, Microsoft has made a point of locking down the Windows Phone 7 specification, despite its multiple manufacturers, requiring Qualcomm Snapdragon for the chipset, specific hardware features, and a relatively unmolested GUI. If Microsoft continues along these lines, it will be hard for Nokia to be truly distinctive. On the other hand, if it abandons them, then it risks spoiling the consistency of the platform.

Another big question relates to tablets. Microsoft has no announced tablet strategy, except insofar as it is not using the Windows Phone 7 OS for tablets and has hinted that the next full version of Windows  will be tablet-optimized. By contrast, both Apple and Google support both smartphones and tablets with a single OS; indeed, it is hard to define the difference between a small tablet and a smartphone. Here at Mobile World Congress, Viewsonic told me that a 4” screen defines it: less than that, it’s a smartphone; more than that, it’s a tablet.

What are Nokia’s tablet plans? Will it change Microsoft’s mind, or wait for Windows 8 following meekly in Redmond’s footsteps, or do something with MeeGo?

Elop has also in my view made a mistake in shattering Nokia’s Qt-based developer community. Qt was the unifying platform between Symbian and MeeGo, and could have been the same for Windows Phone 7. Why? Here’s what Elop told us on Sunday:

What is happening to Qt: “Will Nokia put Qt on Windows Phone? No that’s not the plan. Here is the reason. If we, on the Windows Phone platform, encourage a forking between what natively is provided on the Windows Phone platform and Qt, then we create an environment where potentially we could confuse the developers, confuse the consumers, and even create an environment where Windows Phone could advance slower than the competition because we are carrying two principal development platforms.

I respect Elop; but I think he has been sold a line here. Developers are not easily confused – how patronising – and Windows Phone already has a native code SDK, available to operators and manufacturers. Many of Microsoft’s own applications for the phone are native rather than Silverlight or XNA. In principle, there is no reason why consumers would be able to tell the difference. I think Microsoft is protecting its own development stack and sacrificing Nokia’s developer community in the process.

On a more positive note, I do not forget that Elop is a software guy. I think he recognises that unless you are Apple, hardware commoditisation is inevitable whatever OS you choose. Asked about Windows Phone, the Huawei exec at this morning’s briefing said his company would consider it when the next version comes out. What he means is: if the demand is there, they will make it. If they make it, then Nokia is competing with the same economies of scale and labour that apply to Android.

Elop sees an answer in apps, ads and services: the ecosystem about which he constantly reminds us. On Sunday he noted that the partnership with Microsoft includes an advertising platform, and that this is potentially a significant source of future revenue. The new Nokia may be a lesser company than the old, but one that is better able to survive the challenge of making money from handsets.

Qt will not be ported to Windows Phone 7 says Nokia

Director of the Qt Ecosystem Daniel Kihlberg has posted officially on the future of Qt, Nokia’s cross-platform application framework.

However you spin it, Nokia’s change of direction, relegating Symbian to low-end phones and focusing on Windows Phone as its Smartphone platform, is not good for Qt developers. Kihlberg offers a glimmer of hope for MeeGo though. Whereas CEO Stephen Elop was almost dismissive of MeeGo, saying that a device would be released as part of a learning process, Kihlberg positions it as a source of future disruption:

Nokia also announced it will ship its first MeeGo-related device in 2011, which will rely on the Qt ecosystem – and then will continue with MeeGo as an open source project for future disruption.  Nokia can’t afford to be behind the next disruption again and Qt can play an important role in making sure it isn’t.

But why not port Qt to Windows Phone, which needs a native development stack? Nokia’s Aron Kozak states in a comment:

Qt will not be ported to Windows Phone 7. One of the key benefits of joining an established ecosystem is that there is an established toolchain that everyone uses. All Windows Phone apps will run on all WP7 devices. Adding Qt to the mix would only cause fragmentation.

Unfortunate from a Qt perspective but wise from a developer ecosystem perspective.

In truth, this is near-fatal for the future of Qt at Nokia:

I have to say, Nokia made a bad decision jumping to WP7 knowing that Qt wouldn’t be on it. Now that Nokia did this, they basically went from Qt “Code once, run everywhere” to “Code once, run nowhere”.

says developer Keith Rusler.

The other problem is that developers feel misled:

When Elop came in he said that Qt will be the main framework. Symbian and MeeGo would be unified through Qt. We all stopped working on Symbian C++ and started learning Qt. We have now wasted 6 motnhs of our family’s lives on a dead end. If I knew this was going to happen, I would have started learning Java instead!

Irrespective of the business merits of Elop’s decision, the truth is that its relationship with developers has been deeply wounded. I am not sure how it could have been better handled – except that I think Nokia should have insisted on Qt support in Windows Phone – but I still observe that it has been handled badly. The evidence suggests that Elop under-estimates the importance of nurturing developers in the ecosystems he talks so much about.

Nokia plus Windows Phone 7 – would that be a smart move?

The rumour is that Nokia’s CEO, ex-Microsoft Stephen Elop, is planning a major strategy announcement on Friday February 11. The obvious move would be to embrace a new Smartphone platform, since neither Symbian nor MeeGo look likely to catch up with frontrunners Google Android or Apple iPhone. Could Elop be planning to partner with his former company and embrace Windows Phone 7?

It is a fascinating proposition. Here is the case in favour. For both Nokia and Microsoft, Android is the key competition in this market. The momentum behind Android is deterring both phone manufacturers and operators from investing seriously in Windows Phone 7. Microsoft’s phone is well-regarded, but has made little impact on the general public. Nokia could change that; it could make beautiful Windows 7 phones and get them to the mass market.

Microsoft has also done a good job with the developer tools for Windows Phone 7, with Visual Studio 2010, Silverlight, XNA, and the .NET Framework.

On the other hand, if Nokia were to adopt Windows Phone 7 for its high-end phone platform, would it not alienate its own development community, which is oriented towards Linux and C/C++? I think it would, unless Nokia insisted that as part of its deal with Microsoft, Windows Phone 7 would also support native code development with Qt, Nokia’s cross-platform application framework. This would be great news for Microsoft as well, though it might not recognise it. Windows Phone 7 needs to allow native code development, and Qt is ideal for the purpose. Qt already supports Windows CE, which underlies Windows Phone 7. If Nokia could present Windows Phone 7 as just another platform for Qt, the deal would be palatable for existing Nokia developers.

If Nokia were to announce this, it would transform the prospects for Microsoft’s Smartphone OS as well as helping Nokia to make a renewed impact.

Now for the case against. I am not sure that Qt on Windows Phone 7 would be acceptable to Microsoft, which might prefer to keep developers locked to Visual Studio and .NET; and Nokia has an easy alternative, which is to adopt Android instead. Qt support is still an issue, but there is already an independent project to bring Qt to Android. The combination of the Android and Nokia brands has obvious appeal, whereas taking on Windows Phone 7 would be risky.

The biggest shadow over Windows Phone 7 is cast by Microsoft itself. I do not doubt the commitment of the team which builds it within Microsoft, nor the quality of the developer tools. I do question though whether Microsoft as a whole sees a long-term future for Windows Phone 7 and its “Metro” user interface. The strong hint at CES was that Windows 8, rather than Windows Phone 7, is the basis of Microsoft’s tablet strategy; and if that proves to be the case, then Windows Phone 7 may gradually be displaced. Another puzzle is how Microsoft intends to use “Jupiter”, a rumoured new user interface library for Windows that may well be designed with mobile and touch control in mind. Maybe full Windows with “Jupiter” is the future of Microsoft’s mobile platform, rather than Windows Phone 7? I discuss this in more detail here.

There is enough uncertainty around Windows Phone 7, and enough buzz around Android, that Google’s mobile platform looks to me more attractive than Microsoft’s from Nokia’s perspective. I do not dismiss the Windows Phone idea though; it would be a bold and interesting move.

I expect this post to be very out of date soon, if not by Friday, then certainly by early next week at Mobile World Congress.

Update: A Nokia and Microsoft partnership is looking more likely since Google’s Vic Gundotra tweeted:

#feb11 "Two turkeys do not make an Eagle".

Nokia Maemo, Intel Moblin gives way to MeeGo

Nokia’s Maemo operating system, a Linux distribution for mobile devices, is being merged with the Intel-sponsored Moblin distribution to form MeeGo, under the direction of the Linux Foundation:

MeeGo combines Intel’s Moblin and Nokia’s Maemo projects at the Linux Foundation to create one open source uber-platform for the next generation of computing devices: tablets, pocketable computers, netbooks, automotive IVI and more.

says the Foundation’s Jim Zemlin.

Watching the joint Intel and Nokia interview it seemed to me that this is more Maemo than Moblin, especially since Nokia’s Qt framework and Qt Creator IDE is mentioned as the primary application development platform for MeeGo.

The most significant factor is that Intel and Nokia will now be backing the same mobile OS. You would expect this to have an impact, though I guess the move is an attempt to win back mindshare that has gone to Android, the up and coming mobile OS from Google.

Although both Android and MeeGo are based on Linux, the Android OS has a completely different development model based on Java rather than C/C++.

Is Apple iPhone now unstoppable in the mobile platform wars?

I’ve been reflecting on a chat I had with a mobile application developer at Qt Developer Days last week. He thinks that Apple has all-but won in the battle to dominate the SmartPhone platform.

His reasoning is based on a couple of things. The first is that Apple is easily outpacing others in application availability and number of app installations. I guess there are many ways of counting this, but have a look at these figures. Handango, which has been in this game for over a decade, reported in January that it had over 140,000 apps and 100 million all-time downloads across a number of SmartPhone platforms. Apple reported this month that it has 85,000 apps and 2 billion downloads.

His second point is that Apple is one of the few companies to understand that users like consistency better than choice. “If I pick up an iPhone, my fingers know what to do,” he told me. This makes users reluctant to switch, except to another iPhone. By contrast, Nokia has a zillion different devices supposedly tailored for the needs of different customer segments, but as a result there is no sense of a consistent platform and users can easily switch away. Windows Mobile has the same problem but with multiple vendors as well as frequent design changes from each vendor.

These are points well made. If the much-rumoured Apple tablet appears, we can expect the App Store concept to extend its reach to larger devices as well. No wonder Adobe is so determined not to be left out on this platform, announcing a compiler to convert Flash applications to native iPhone code, as well as stepping up its campaign for Flash in the iPhone browser.

That said, I can think of counter-arguments. One is that iPhone isn’t yet, as far as I know, strong for corporate development. Windows Mobile has some advantages here, for Microsoft platform companies, while Java (not available on iPhone so far) is also appealing to corporate developers.

Another is that Google Android will give strong competition and take advantage of Apple’s weakness, its reluctance to abandon premium pricing.

Third, the consistency argument only goes so far. If you look at today’s iPod touch, for example, compared to the first iPods, there are huge differences. Users will in fact switch if there is convincing value in what is new.

Fourth, the more iPhone grows in importance, the more discontent over the closed nature of its platform will grow.

It is still early days for SmartPhones as a development platform; and while it is fun to speculate, things may look very different in a couple of years.

Still, let’s acknowledge that right now it is advantage Apple.

See also: What’s your choice in the mobile battleground?

and this great rant from a frustrated Symbian/Nokia developer:

Calling all Nokia & Symbian geniuses: Am I wrong?

Qt goes mobile, gets bling, aims for broader appeal

Here at Qt Developer Days in Munich we’ve heard how Nokia wants to see “Qt everywhere”, and will be supporting Qt on its Maemo operating system and on Symbian, as well as adding specific support for Windows 7 and Mac OS X 10.6, “Snow Leopard”. Qt already works on Microsoft Windows Mobile, and of course on Linux which is where it all started. What about Google Android, Palm WebOS, Apple iPhone? Nothing has been promised, but there is hope that Qt will eventually work on at least some of these other systems.

So is “Qt everywhere” a realistic proposition? Here’s a few impressions from the conference. First, a bit of context. Qt is a C++ framework for cross-platform development. and although bindings for other languages exist, Nokia says it is focused on excellence in C++ rather than working with multiple languages. Developers get the advantages of both native code executables and cross-platform support, and Qt is popular on embedded systems as well as desktops and mobile devices.

Qt is an open source framework which was developed by a company called Trolltech which Nokia acquired in 2008. Its motivation, one assumes, was to simplify development for its own multiple operating systems, especially Maemo and Symbian. Still, it has also taken its responsibilities to the open source community seriously. Qt was originally available either under the GPL, which requires developers to make their own applications available under the GPL as well, or under a commercial license. This limited Qt’s take-up. In March Nokia introduced a third option, the LGPL, which is a more liberal and allows commercial development using the free license. The result, we were told, has been a 250% increase in usage (though how this is defined is uncertain) accompanied by “a small drop in revenue.”

Although the revenue decrease is troubling, it is not a disaster for Nokia whose main business is selling hardware; and if take up continues to increase I’d expect revenue to follow.

Since the Nokia acquisition, Qt has been energetically developed. 2009 has seen the release of a dedicated IDE called Qt Creator. I was interested to see a company that has chosen not to go the Eclipse route for its primary IDE, though there are plug-ins for both Eclipse and Visual Studio. The trolls explained that Eclipse came with too much baggage and they wanted something more perfectly suited to its purpose, a lean approach that is in keeping with the Qt philosophy.

Another important move is the inclusion of Webkit within the framework, the same open source HTML engine that powers Apple’s Safari, Adobe AIR, and the browser in numerous Smartphones. Webkit also comes with a Javascript engine, which Nokia is exploiting in several interesting ways.

The big deal at Qt Developer Days was another new project called Kinetic. This is comprised of four parts:

1. An animation API.

2. A state machine.

3. A graphical effects API.

4. A declarative API, currently called QML (Qt Markup Language), though this may change.

Many of these pieces, though not the last, are already present in Qt 4.6, just released in technical preview. Nokia has not announced a specific date for Kinetic, though there were mutters about “first half of 2010”.

The thinking behind Kinetic is to make it easier to support the graphical effects and transitions that users have come to expect, as well as improving the designer-developer workflow – showing that it is not only Adobe and Microsoft who are thinking about this.

QML is significant for several reasons. It is a JavaScript-like API: we were told that Nokia started out with XML but found it cumbersome, and settled on JavaScript instead. It is designed to work well with visual design tools, and Nokia has one code-named Bauhaus which will be part of Qt Creator. Finally, it allows snippets of JavaScript so that developers can create dynamic user interfaces.

At runtime, QML is rendered by a viewer widget, which can be programmatically controlled in C++ just like other Qt widgets.  

Nokia’s hope is that designers can be persuaded to work directly in the QML designer, enabling free exchange of code between designers and developers. It is a nice idea, though I doubt designers will easily transition from the more comfortable world of Photoshop and Flash. However, even if in the end QML is used more by developers than designers, it does greatly simplify the task of creating a dynamic Qt UI. Note that there is already a visual GUI designer in Qt Creator but this is geared towards static layouts.

Long term, who knows, we may see entire applications written in QML, opening up Qt to a new and broader audience.

You can see the latest Qt roadmap here.

Qt pros and cons

I was impressed that attendance here has increased – from around 500 last year to around 700 – despite the economy. Those developers I spoke to seemed to like Qt, praising the way it self-manages memory, though some find the model-view aspect too complex and apparently this is to be improved. Nokia’s stewardship and openness is appreciated and the Qt roadmap generally liked, though there is concern that its understandable focus on mobile may leave the desktop under-served.

Cross-platform capability is increasingly important, and for those who want the performance and capability of C++ along with really good Linux support – important for embedded use – Qt is a strong contender. The focus on mobile is right, not only because of Nokia’s own needs, but because demand for Smartphone apps can only increase.

Integrating with Webkit is a smart move, opening up possibilities for hybrid web/desktop applications and giving Windows developers an alternative to embedded IE with all its quirks.

The open source aspect is another strength. This is now a good selling point if you developing for certain governments (the UK is one such) or other organisations that have a bias towards open source.

That said, talk of Qt everywhere is premature. The mobile space is fractured, and without iPhone, WebOS or Android Nokia cannot claim to have a universal solution. Nor has anyone else; but I’m just back from Adobe MAX where we heard about wider support for the Flash runtime. Then again, few choose between C++ or Flash; Adobe’s runtime is pretty much off the map for attendees here.

Qt is well-established in its niche, and is in good hands. I will be interested to see whether Nokia is successful in broadening its appeal.

Incidentally, if you can get to San Francisco you can still catch Qt Developer Days as it is running there from November 2nd-4th.

From Flash to Qt: different tech, same themes

I’m at the Qt Developer Days in Munich, hearing the latest from Nokia on its cross-platform GUI framework. Qt was originally developed by Trolltech, a company acquired by Nokia, and the Qt folk here still call themselves trolls.

So what are the trolls up to? Coming straight from the Adobe MAX conference last week, I’ve been interested to find that many of the themes are the same: mobile, hybrid web/local applications, and even designer/developer workflow.

The obvious difference is that Qt is a C++ framework and most of the developers I’ve spoken to here use Linux and C++, both rare skills at an Adobe event. Still, it seems that may be changing. “Wouldn’t be good if designers and developers could work on the same project?” said Matthias Ettrich,as he introduced QML, a declarative UI language for Qt. Now where have I heard that before?

An interesting feature of QML is that it supports Javascript as well as layout and state definition; in fact, QML definitions are really Javascript expressions. This means you can program entire applications in QML, though you can also use it purely to define the visual part, and code the rest of your application in C++. A QML layout looks like any other Qt widget to your C++ code.

But let’s get back to the idea of coding purely in Javascript. Ettrich explained how this would enable designers to add logic and state management to applications, without needing C++ skills. QML projects live in Qt Creator, the same IDE commonly used for C++ Qt applications. This echoes how Adobe presents Flash Catalyst, the new “interaction designer” for the Flash platform. Another parallel is that we saw at MAX how Catalyst can be used to create entire applications, provided that they are simple in nature.

It strikes me that QML has the potential to open up Qt to a much wider developer audience, one that never wants to touch C++. It is also amenable to visual design tools, and for those C++ developers who are not 100% averse to such things it is likely to prove popular.

Trolltech says Qt for Windows CE coming in May

Trolltech has announced Windows CE support in the 4.4 release of Qt, its cross-platform development framework. A pre-release is already available. Qt already supports desktop Windows, Linux, and Mac OS X, so this plugs a significant gap. Features include SVG (Scalable Vector Graphics) and OpenGL. It’s good to see this going ahead  despite Nokia’s acquisition of Trolltech, which is set to be completed in the second quarter of 2008. Nokia is committed to a couple of rival embedded operating systems, Linux and Symbian.

What about Qt for Symbian then? There are hints that it will happen. Then again, perhaps Nokia will increase its focus on Linux?

Technorati tags: , , ,