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.
Thread beginning with comment 472485
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Meh
by vivainio on Tue 10th May 2011 09:14 UTC in reply to "RE[3]: Meh"
vivainio
Member since:
2008-12-26


I should point out on the ui level silverlight is a pretty similar concept to QtQuick but uses XAML instead of javascript.


The big difference between QML and XAML is that you just can't add nontrivial logic to XAML; all the logic ends up in C# file. XAML can only do the "declarative" part, i.e. you can do simple bindings there.

You can start going on about enforcing the separation of concerns as being a good thing, but you would only be covering up inherent flaws of selecting XML as the ui annotation technology ;-).

From what I've seen of qtquick binding to the ui is not as intuitive as in silverlight.


What does this mean?

Reply Parent Score: 2

RE[5]: Meh
by _txf_ on Tue 10th May 2011 09:51 in reply to "RE[4]: Meh"
_txf_ Member since:
2008-03-17

You can start going on about enforcing the separation of concerns as being a good thing, but you would only be covering up inherent flaws of selecting XML as the ui annotation technology ;-).


you'll get no argument from me there


"From what I've seen of qtquick binding to the ui is not as intuitive as in silverlight."

What does this mean?


It could be from my lack of familiarity. Or it might stem from silverlights more complete widget library but there are more explicit/predefined ways of binding events to the underlying logic or exposing events to the ui layer (the whole Model View ViewModel thing).

Then again the ViewModel approach is not required in Qt quick due to the ability to do as you said non-trivial logic can be done in the ui layer.

(just for clarity the view-model is essentially the controller architected as a model for the ui, the view is almost pure graphics and the model is the same as always).

Reply Parent Score: 2

RE[6]: Meh
by vivainio on Tue 10th May 2011 09:57 in reply to "RE[5]: Meh"
vivainio Member since:
2008-12-26

Or it might stem from silverlights more complete widget library


Ah, you were contrasting against raw qml. Luckily we have Qt Quick Components hitting production status in the following few weeks:

http://confusingdevelopers.wordpress.com/2011/04/01/intels-qt-quick...

http://labs.qt.nokia.com/2010/09/10/building-the-future-reintroduci...

Reply Parent Score: 2

RE[5]: Meh
by Nelson on Tue 10th May 2011 13:17 in reply to "RE[4]: Meh"
Nelson Member since:
2005-11-29


The big difference between QML and XAML is that you just can't add nontrivial logic to XAML; all the logic ends up in C# file. XAML can only do the "declarative" part, i.e. you can do simple bindings there.


You can do multibinding, binding to ancestor, element bindings, binding with data validation, binding to pure XAML data sources, priority binding, result filtering in XAML.. ?

PLUS really anything else under the sun you can imagine by creating a markup extension (Hint: "{Binding ...}" is simply a built in markup extension.)

But it speaks to a greater issue, and its a valid one, which is testability and that of a separation of concern.

The fundamental look of a View, and the mechanics behind that view, should be separate things in my opinion. This is the difference between a View (which should be pure XAML ideally, and a ViewModel which is simply an adapter for the Model).

So in my View I handle the layout, where bindings will appear, and do all the visuals (animations, caching brushes, freezing resources, etc..)

The ViewModel is where you'd communicate with the model and turn its platform agnostic data into Wpf/Sl specific entities .. you can also optionally present different values for design time and run time so I can see what my UI will look like without having to run my project.

The separation is an important one, and I'm glad its like that (for those who really have a problem with it: you *can* use inline code in XAML, though not in Silverlight iirc). Intermixing logic with my UI code in QML doesn't sound like my cup of tea.



What does this mean?


XAML is directly woven into the .NET object model. Every XAML element corresponds to a .NET Element 1:1. I can traverse them using C# and have first class support inside the IDE.

Besides, Javascript is such a yuck language to use when compared to C# for these kind of things. A typeless, completely dynamic language is really an abomination .. and should never be a part of the picture moving forward.

Hell, I'd rather do C++/QML than deal with the incoherent mess that is Javascript/QML.

Reply Parent Score: 3

RE[6]: Meh
by vivainio on Tue 10th May 2011 13:43 in reply to "RE[5]: Meh"
vivainio Member since:
2008-12-26


You can do multibinding, binding to ancestor, element bindings, binding with data validation, binding to pure XAML data sources, priority binding, result filtering in XAML.. ?


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?

PLUS really anything else under the sun you can imagine by creating a markup extension (Hint: "{Binding ...}" is simply a built in markup extension.)


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

Intermixing logic with my UI code in QML doesn't sound like my cup of tea.


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.



XAML is directly woven into the .NET object model. Every XAML element corresponds to a .NET Element 1:1. I can traverse them using C# and have first class support inside the IDE.


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.

Besides, Javascript is such a yuck language to use when compared to C# for these kind of things. A typeless, completely dynamic language is really an abomination .. and should never be a part of the picture moving forward.


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.

Hell, I'd rather do C++/QML than deal with the incoherent mess that is Javascript/QML.


I also opted to go C++/QML first, but later changed my mind - almost everything could be done in QML/js in a more succinct way.

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.

Edited 2011-05-10 13:43 UTC

Reply Parent Score: 2