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 472484
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Meh
by _txf_ on Tue 10th May 2011 09:09 UTC in reply to "RE[2]: Meh"
_txf_
Member since:
2008-03-17

It's a much neater concept than e.g. with C# / Silverlight, where you are forced to write almost everything in C#


I should point out on the ui level silverlight is a pretty similar concept to QtQuick but uses XAML instead of javascript. From what I've seen of qtquick binding to the ui is not as intuitive as in silverlight.

I don't like javascript that much (probably due to lack of familiarity) but its syntax is far cleaner than XML (it gets worse when using a tool like expression blend as it literally vomits out XML tags).

Everything else is very true, but that has been the tradeoff with managed languages since forever...

Edited 2011-05-10 09:11 UTC

Reply Parent Score: 2

RE[4]: Meh
by vivainio on Tue 10th May 2011 09:14 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[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