Linked by Thom Holwerda on Mon 9th May 2011 21:14 UTC, submitted by Elv13
Qt Since Nokia announced its switch to Windows Phone 7, people have been worried about the future of Qt. Well, it turns out Nokia is still going full steam ahead with Qt, since it has just announced the plans for Qt 5. Some major changes are afoot code and functionality-wise, but the biggest change is that Qt 5 will be developed out in the open from day one (unlike Qt 4). There will be no distinction between a Nokia developer or third party developer.
Permalink for comment 472593
To read all comments associated with this story, please click here.
RE[7]: Meh
by Nelson on Tue 10th May 2011 19:14 UTC in reply to "RE[6]: Meh"
Nelson
Member since:
2005-11-29


Ok, so lets say "you can only do binding in xaml" instead. As an example, can you invoke XHR in xaml and store the result in a database?


Yes you can. You can declaratively do it with XmlDataProvider (WPF only unfortunately). You can subclass it and override OnQueryFinished to insert it to a database, but really I don't see the point.

You're polluting the View with needless behavior though. Any good performance programmer will tell you "Cache implies policy" and policy is best defined in the ViewModel, not in the View.

The View is supposed to be reusable, replacable, and testable (UI Automation) having any kind of logic in the View outside what is absolutely necessary is breaking this workflow.


Let me wager "markup extensions" need to be written in C#?


Yes, but also every <Button> corresponds to a Button control (written in C#) so a markup extension you define in XAML being written in C# is not a huge deal, and in fact, it is no different from what QML does.


It's not for everyone, but it's pretty damn powerful and agile. You can do janitorial tasks like moving inline stuff out later, if you find it offensive. Just having the option to do it makes QML more expressive.


That would make sense if you couldnt use inline code in XAML with WPF, but you can. Also, is it really that much of a hassle to wire up an event handler? i mean if you absolutely must break the MVVM programming pattern, do it in a less disgusting way.


In QML, everything is a QObject (or QDeclarativeItem) as well. There is no "code generation" like with XAML, though. I don't really miss it.


I don't get what you mean. QML, like XAML in Silverlight is loaded, parsed, interpreted, and generated at runtime into the corresponding Qt objects.

XAML on the other hand in WPF is compiled to BAML, which is even faster than interpreting QML or XAML.


Javascript is not typeless, it's dynamically typed (like Python, Ruby...). It's yuckier than many other languages, but it's pretty much here to stay - and as it appears, it's a valuable skill to learn in todays job market, so tons of people know the language.


Like I replied in another post, weak typing is effectively no typing, because implicit conversions beyond a few base types (integers, strings) are a largely undefined operation, which can cause all sorts of problems with functions not designed to handle them.

It's more work, more room for error, and a lot slower than compiled C#. So why use it?


XAML has a killer flaw that makes it irrelevant to most people here though - it's neither open, nor truly cross platform (win + mac != cross platform). QML, OTOH, is something everyone can pick up and start using.


Its also a lot less mature than XAML, and in my opinion, a lot less easier to work with, the relationships between parent/child nodes are much more pronounced.

XAML is absolutely open, its vocabulary is covered under Microsoft's OSP.

At the end of the day though, QML is good, it's great, and I think I said that earlier. However, QML being great doesn't make Silverlight/Wpf/Xaml bad, or inferior.

Reply Parent Score: 2