[Interest] Qt on Windows Phone 8

[Till Oliver Knoll]

2012/6/21  <song.7.liu at nokia.com>:
> ...
> So the developer can write the application with C++/XAML, C#/XAML, JS/HTML5, then how about the C++/QML pair? It seems to be similar with C++/XAML...

On desktops you can develop using C or Java. Or C++. Or Pascal. Or C#.
Or Eiffel. What about Pythong? Yes, works out, too...

> Personally, I don't like this duplication...

Call it "Freedom of Choice"(tm) then :) (Or alternatively: "I'd like
to use the tool which suits my problem field or experience best").

> Else if you start to write a new apps you can use the C++/XAML if you choose native code...

It is not only about native code (even though I'm a great fan of
that). It is also not only about C++. It is about C++ AND Qt. We just
recently had the discussion here how nicely one can avoid the use of
STL - std::string as an example - when using the Qt equivalent
containers/classes. Some people prefer to use the STL - some people
simply don't ;)

Some people simply think that Qt/C++ is the most pleasant way to
develop applications :)

But most importantly it is also about cross-platform compatibility:
you might want to re-use as much as possible of your code to run it on
another platform. (Even though "compatibility" implies "it runs on a
best effort basis" - but in most cases that is absolutely acceptable.)


Now there are people implying that Microsoft is totally evil and wants
you make to use only their technology. Now I am not a mobile phone
application developer, but I imagine at the current point Microsoft
couldn't care less in what technology the "apps" are written in - as
long as there would be apps for Windows Mobile - no? (And off course
as long as those applications would comply with their "App Store"
rules).

Even Apple accepts Qt applications in their *desktop* App Store. Yes,
they do have some restrictions ("no 3rd party WebKit module", "No call
to non-public Cocoa/etc. APIs", very strict rules about
sandboxing/where your app is allowed to read/write", ...). But as long
as you make sure that your application won't download external
functionality "without Apple seeing a dime" Apple probably cares less
about the actual technology/toolkit being used than one might think.

And I think the same holds for Microsoft.


As for iOS, I've heard that "No JavaScript interpreter allowed" is a
problem to properly port Qt/QML on the iPhone/iPad (that comes from
the App Store rule that "No interpreter allowed" - not specifically
JavaScript).


So in the end it is all about "making sure we get paid for every
functionality the App offers" (economical reasons) rather than trying
to lock out other languages or frameworks - even though in practise
that can mean "dead end" for a given technology/toolkit/framework.


Cheers,
  Oliver