When Stephen Elop announced Nokia was adopting Windows Phone 7 as its main development platform for the future, many of us felt a mix of fear for our jobs, incredulousness (are they committing suicide?), anger for betraying open source, then curiosity. What’s this WP7 about and what’s up in regards to development?
The canonical development platform for WP7 consists of Visual Studio 2010 and managed applications developed in .NET 4 using C# as the programming language and a WPF for the user interface. If you are not into .NET, you may be a bit lost now.
Windows Phone 7 is an embedded operating system by Microsoft. It is the successor to Windows Mobile 6.5 but it is incompatible with it and it is targeted at mobile phones.
Visual Studio is Microsoft’s development environment, including IDE, compiler, debugger, profiler and much more. In my opinion, it is one of the finest applications Microsoft has developed. It is many years ahead of QtCreator, KDevelop, Eclipse or anything else.
.NET is a framework Microsoft started more than a decade ago. It includes libraries, a language independence infrastructure, memory management, localization and many more features. Applications can be compiled as native code (for x86 or x64), or as managed code (bytecode). .NET also includes a bytecode JIT compiler. You can target the .NET platform in many languages, including but not limited to, Visual Basic .NET, C#, F#, C++/CLI (it’s NOT the C++ you know!), etc
Interestingly, you can also compile normal C++ to .NET but it will have unmanaged code (i. e. code where memory allocations/deallocations are performed by you instead of the runtime, and pointers). WP7 requires that all code that runs on it be managed. This means that Qt cannot run on WP7, even though it may be compiled targetting the .NET platform and it would run on desktop operating systems.
C# is a multi-paradigm programming language developed by the father of Delphi. It is very powerful and looks a lot like C++2011. When I was learning C#, I couldn’t but think what the actual implementation of C# features were behind the scenes, in C and C++.
WPF is Windows Presentation Foundation (formerly known as Avalon), the technology (library) used for the GUI. In plain terms, it’s a library which provides accelerated everything for Windows applications: widgets, 2D, 3D, scalable graphics, etc
When developing UIs in WPF, you can either use C# code:
// Create a Button with a string as its content. Button stringContent = new Button(); stringContent.Content = "This is string content of a Button"; // Create a Button with a DateTime object as its content. Button objectContent = new Button(); DateTime dateTime1 = new DateTime(2004, 3, 4, 13, 6, 55); objectContent.Content = dateTime1; // Create a Button with a single UIElement as its content. Button uiElementContent = new Button(); Rectangle rect1 = new Rectangle(); rect1.Width = 40; rect1.Height = 40; rect1.Fill = Brushes.Blue; uiElementContent.Content = rect1; // Create a Button with a panel that contains multiple objects // as its content. Button panelContent = new Button(); StackPanel stackPanel1 = new StackPanel(); Ellipse ellipse1 = new Ellipse(); TextBlock textBlock1 = new TextBlock(); ellipse1.Width = 40; ellipse1.Height = 40; ellipse1.Fill = Brushes.Blue; textBlock1.TextAlignment = TextAlignment.Center; textBlock1.Text = "Button"; stackPanel1.Children.Add(ellipse1); stackPanel1.Children.Add(textBlock1); panelContent.Content = stackPanel1;
or use XAML, which is an XML-based language for WPF:
<!--Create a Button with a string as its content.--> <Button>This is string content of a Button</Button> <!--Create a Button with a DateTime object as its content.--> <Button xmlns:sys="clr-namespace:System;assembly=mscorlib"> <sys:DateTime>2004/3/4 13:6:55</sys:DateTime> </Button> <!--Create a Button with a single UIElement as its content.--> <Button> <Rectangle Height="40" Width="40" Fill="Blue"/> </Button> <!--Create a Button with a panel that contains multiple objects as its content.--> <Button> <StackPanel> <Ellipse Height="40" Width="40" Fill="Blue"/> <TextBlock TextAlignment="Center">Button</TextBlock> </StackPanel> </Button>
More or less, WPF is to .NET what QML is to Qt.
Ouch. This WP7 is completely different to what we are used to. Maybe we can make them less different?
People tend to believe WPF and XAML are the same thing. They are not. XAML is one of the languages (which happens to be used by 99.99% of the people) to write applications in WPF but it is not the only one. You can write WPF applications in C# code (it’s not unusual to mix XAML and C#, what we call “code behind” in WPF parlance), or you could create your own XAML-equivalent language.
Or you could make my wish for today true: create a compatibility layer for QML to be able to develop WPF applications in QML, effectively replacing XAML. It is technically possible. This will also require a glue-layer for C#, similar to what we have now to bridge QML and C++. This would make porting applications from C++ and QML to C#, QML and WPF a relatively easy task, and may provide realistic path to convert Qt applications to WP7 withouth a full rewrite.
Update Fixed XAML vs C# code, thanks ‘aa’. Also, please note using C++ with QML WPF would be straightforward
It is both XAML
Could you explain to us why the open source have to do any effort for a compagny that basically destroy a lot of projet link to them and another one which declare themselve a “jihad” against it?
I do not see any reasons to provide any good software to help them to save their system to be doom.
The only problem with QML, it isn’t to the level at which WPF is. If QML ever gets to that point, I might use it. I mean like “Button”, “MenuBar”, “StatusBar”, etc.
Windows phones doesn’t really exist on the market and this probably won’t change any time soon. Windows Phone 7 is just crap. The most important is to write applications for Android which is Linux based and where nobody forces programmers to use crappy slow and bloated c# .net.
Qt Components are the answer.
But I really like this idea, actually I was thinking about the same.
Cool idea! And why the hell not? Despite of what some people may think – this is not a Holy War!
For the uninitiated of us, could you explain to us the difference between QML and WPF’s “level”?
I think you may have shown poor judgement in posting this to Planet KDE, or at least a lack of an awareness of the context in which your posting would appear, the audience of the publication and your responsibilities in contributing to it.
Your post is about calling into a proprietary toolkit to write software for a proprietary platform that doesn’t allow GPL’d software in the only conduit available to deploy software on it. That’s somewhat at odds with the general thrust of the KDE community – fundamentally a free software community, although one that plays host to a wide range of beliefs of course – and your post doesn’t address any of those aspects, which comes across as glaring oversights.
I find it somewhat disconcerting to imagine someone browsing to Planet KDE, reading your post and walking away with the impression that the KDE community is happily following along with a strategy decision by Nokia that clearly takes it further away from free software rather than closer to it.
All it would have been nice if you had put more thought up-front into whether this would fit into the Planet KDE context at all, or at least shown enough foresight to explain how and why you think this idea would be relevant to KDE in spite of the constraints of that platform and thus acknowledging them.
While I think that free software is particularly successful because it is technically much more flexible and at times even more pragmatically when it comes to support different platforms and solutions (even closed source ones), it is definetly true that free software needs a strong focus on free technologies (aka ethics as stated by the FSF). If you get sidetracked to support proprietary platforms which discriminate explicetly against you then you might increase your work in the long term significantly.
Therefore you should really think about the context in which this should happen. I think the other way around, where porting .net applications to Qt would be targeted would be of much greater benefit than walking in the .net trap.
It might be a good technology, but every technology becomes poor when it gets locked up and is limited by the interests of its owner, so no matter how popular .net might be, it will not succeed in the long run. This is the lesson we are learning all the time with FOSS.
1) there are Binding Qt to .Net (Qtsharp Qyoto) so you can use Qt in managed applications (however they need unmanaged qt )
Geting all together you can get QML runtime for .NET. And packing WPF objects into QML objects you can get what you want.
What do you think about this idea?