Tag Archives: qt

Will Nokia’s Qt come to Windows Phone?

When Nokia acquired Trolltech back in 2008, it made perfect sense as a way of supporting development on Symbian, its smartphone operating system, and nudging the Qt project, which provides a cross-platform framework for native applications, more towards mobile rather than just desktop application support. It also made sense as Nokia worked on Maemo and then Meego, its Linux for mobile project.

Then came February 2011 and CEO Stephen Elop’s announcement that Nokia would partner with Microsoft and make Windows Phone its primary smartphone operating system. Windows Phone 7 does not support native code development, other than by operators, manufacturers, and of course Microsoft itself. What future for Qt at Nokia now?

Here at Blackberry Devcon Europe, Nokia’s Lars Knoll, Qt Chief Maintainer, has been introducing Qt to Blackberry developers. Qt forms a critical part of RIM’s Blackberry 10 (BBX) platform, based on the PlayBook tablet OS and set to come to Blackberry phones later this year. The Cascades UI framework, for hardware-accelerated 2D and 3D rendering on BBX, uses Qt core and an adaption of QML (Qt Modeling Language). You can use Qt with or without Cascades on BBX.

Lars Knol, Nokia

Given that Nokia makes mobile devices which are in competition with RIM’s devices, it may seem odd that Nokia is supporting Qt on Blackberry. I asked Knoll about the status of Qt within Nokia following the move to Windows Phone.

There’s not too much I can say right now. The only thing I can repeat is that we’re still investing in Qt. We’re actually hiring more people to work on Qt. Qt is an essential part of the strategy for the next billion. That’s all I can say right now, but stay tuned, in time you’ll hear more.

He added later that Nokia is in business to make money; in other words, there are strong business reasons for Nokia to continue with Qt. The “next billion” reference refers to Nokia’s stated intention to bring apps to the next billion.

One possibility is that Qt will in fact support a future version of Windows Phone. It is already clear that Windows Phone 8 will use the same kernel as Windows 8 and we can expect a unified development platform build on the Windows Runtime (WinRT), which does support native code development.

It is not too much of a stretch then to expect a future Qt framework that will target Windows Phone and Windows 8 tablets. Nokia’s Elop has also hinted that it is interested in Windows tablets as well as phones in future.

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.

image

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.

Android only 23% open says report; Linux, Eclipse win praise

Vision Mobile has published a report on what it calls the Open Governance Index. The theory is that if you want to measure the extent to which an open source project is really open, you should look at its governance, rather than focusing on the license under which code is released:

The governance model used by an open source project encapsulates all the hard questions about a project. Who decides on the project roadmap? How transparent are the decision-making processes? Can anyone follow the discussions and meetings taking place in the community? Can anyone create derivatives based on the project? What compliance requirements are there for creating derivative handsets or applications, and how are these requirements enforced? Governance determines who has influence and control over the project or platform – beyond what is legally required in the open source license.

The 45-page report is free to download, and part-funded by the European Union Seventh Framework Program. It is a good read, covering 8 open source projects, including the now-abandoned Symbian Foundation. Here is the result:

Open Governance Index (%open)
Eclipse 84%
Linux 71%
WebKit 68%
Mozilla 65%
MeeGo 61%
Symbian 58%
Qt 58%
Android 23%

The percentages are derived by analysing four aspects of each project.

  • Access covers availability of source code and transparency of decisions.
  • Development refers to the transparency of contributions and acceptance processes.
  • Derivatives covers constraints on use of the project, such as trademarks and distribution channels.
  • Community structure looks at project membership and its hierarchy.

What is wrong with Android? I am not sure how the researchers get to 23%, but it scores badly in all four categories. The report observes that the code to the latest “Honeycomb” version of Android has not been published. It also has this to say about the Open Handset Alliance:

When launched, the Open Handset Alliance served the purpose of a public industry endorsement for
Android. Today, however, the OHA serves little purpose besides a stamp of approval for OHA
members; there is no formal legal entity, no communication processes for members nor frequent
member meetings.

By contrast, Eclipse and Linux are shining lights. MeeGo and Mozilla are also praised, thought the report does mention Mozilla’s “Benevolent dictators”:

In the case of conflicts and disputes, these are judged by one of two Mozilla “benevolent dictators” – Brendan Eich for technical disputes and Mitchell Baker for non-technical disputes.

Qt comes out OK but has a lower score because of Nokia’s control over decision making, though it sounds like this was written before Nokia’s Windows Mobile revolution.

WebKit scores well though the report notes that most developers work for Apple or Google and that there is:

Little transparency regarding how decisions are made, and no public information provided on this

Bearing that in mind, it seems odd to me that WebKit comes above Mozilla, but I doubt the percentages should be taken too seriously.

It is good to see a report that looks carefully at what it really means to be open, and the focus on governance makes sense.

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.

MeeGo, Qt, and the new Nokia: developers express their doubts

What are the implications of the new partnership between Nokia and Microsoft for MeeGo, the device-oriented Linux project sponsored by Intel and Nokia? What about Qt, the application framework that unifies Symbian and MeeGo development?

Here is what Nokia says:

Under the new strategy, MeeGo becomes an open-source, mobile operating system project. MeeGo will place increased emphasis on longer-term market exploration of next-generation devices, platforms and user experiences. Nokia still plans to ship a MeeGo-related product later this year.

Nokia is retaining MeeGo but it has moved from centre-stage to become more niche and experimental.

The snag for developers is that there are no known plans to support Qt on Windows phone. According to the letter to developers, Qt developers can look forward to the targeting low-end Symbian devices and at least one solitary MeeGo phone:

Extending the scope of Qt further will be our first MeeGo-related open source device, which we plan to ship later this year. Though our plans for MeeGo have been adapted in light of our planned partnership with Microsoft, that device will be compatible with applications developed within the Qt framework and so give Qt developers a further device to target.

Reaction from developers so far is what you might expect:

By this announcement, I’m afraid you’ve lost many faithful people (developer and consumers) like myself, who’s been a Nokia user ever since I’ve started using cellphones..

and

Wow what can I say, nokia just flat out killed any enthusiasm I had to develop on nokia platforms, I never have and never will use a windows platform. You have just killed QT, even worse killed the most promising OS out there in Meego. Elop is the worst thing that has ever happened Nokia.

and

Weak on execution, you choose to flee. What a sad day in the history of a once proud and strong company.

Nokia could fix this by demanding Qt support for Windows Phone 7.

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++.