Nokia Announces Qt 5 Plans
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.
E-mail Print r 5   · Read More · 52 Comment(s) http://osne.ws/j2h
Thread beginning with comment 472546
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Meh
by vivainio on Tue 10th May 2011 13:43 UTC 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

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