Surely there will be some overhead due to parsing QML at application startup
So that doesn't explain why QML apps are also laggier while running. Also, I like how you ignored everything else I said. If porting all the QWidgets already written to QML is such an easy task then you have all of the ones that ship with Qt now ported over by next week, right?
You mean all the little toy demos that aren't even remotely similar to the needs of a full blown desktop app? I'll believe it's so great when Qt Creator is implemented fully in QML. Oh wait, that's not going to happen as they admitted they will only be using it very sparingly. Since they don't eat their own dog food, I don't buy the hype.
So if QML is so great why do the Qt Creator guys admit they will barely be using it in the Qt5 version of Qt Creator? The reason is is because it doesn't provide nearly the benefit that is claimed otherwise they'd be pressing full on into QML.
Lots of people care about the RIAA, want it gone, and refuse to buy music.
And by "lots of people" you mean "lots of people in your niche group". How many average people in Best Buy who are buying CDs give a rats ass or even have likely ever heard of the RIAA?
Yes, the most non-biased source of information is an employee of the company who originated the technology and was a founding member of the standardization group.
WebGL grew out of the Canvas 3D experiments started by Vladimir Vukievi at Mozilla. Vukievi first demonstrated a Canvas 3D prototype in 2006. By the end of 2007, both Mozilla[6] and Opera[7] had made their own separate implementations. In early 2009 Mozilla and Khronos started the WebGL Working Group.
Sorry, what eventually became WebGL originated from Mozilla and then later Mozilla and Khronos started the working group to standardize it. So yes, you can say it originated from them.
Yes, because the place to get a neutral opinion is someone who works for the company who was the originator of WebGL. Gee, no conflict of interest there...
Don't worry, just like with the previous story they'll just claim it wasn't a flaw in Chrome (despite it bypassing the Chrome sandbox) and downplay it.
Porting a QWidget to QDeclarativeItem is so easy that it could be considered a janitorial task in many projects.
Well then why haven't you ported all the QWidgets over for us by now? It's so quick and easy, right?
Plenty of simple custom QWidgets can be reimplemented in QML with a significant drop in code size, so there's actually a good reason to do that.
That's great if all you ever used were "simple" QWidgets. Many people rely on much more than "simple" widgets for real apps.
The current implementation surely has performance corner-cases, just like early Qt 4.x series had, especially before 4.4.
Thus making it unusable for people who need high performing apps. Most people aren't going to rewrite things in QML just because they are promised that years down the line it will stop being laggier and slower than their current QWidget-based programs.
The performance issues will be worked out, there's no fundamental reason why QML should perform worse than a QWidget-based ui.
Sure, if we ignore the overhead over interpreted code.
Heck, I've found quite a few cases where QLayout-based UIs were stuttering when you resized the windows or dragged splitters
And you've reported these issues?
the QLayout/QWidget infrastructure is seriously broken if you use native widgets, like you had to on OS X for example until very recently.
If by "runs native" you mean it has in the last couple of years moved to use the native drawing APIs of the platform, yes, but it doesn't use the native widgets if that is what you are trying to imply. And for the longest time Qt just faked the native look with themes before using the native drawing APIs.
I think you didn't look at the code. First of all, QML is NOT Javascript. It is a declarative language that integrates seamlessly with Javascript.
More accurately, QML is Javascript with extensions.
As for efficiency: I'd beg to differ. There's nothing inherent in the declarative framework that would make it less efficient than QWidget.
And yet with a simple search of "QML slow" you can find all sorts of examples of QML running slow. All sorts of people are seeing lagginess, etc in QML apps. The best the Qt people have shown have been little toy examples where there may be no noticeable difference. Get back to me when they have a full blown app that has lots of intensive visualization and show me that it has no efficieny issues.
QML has expressive power that makes legacy frameworks look almost silly.
Examples? It really means little to hear people throw out buzzwords and provide no examples of how it is more this or that.
Slashdot Mirror
Surely there will be some overhead due to parsing QML at application startup
So that doesn't explain why QML apps are also laggier while running. Also, I like how you ignored everything else I said. If porting all the QWidgets already written to QML is such an easy task then you have all of the ones that ship with Qt now ported over by next week, right?
Look at any of the demos that come with it.
You mean all the little toy demos that aren't even remotely similar to the needs of a full blown desktop app? I'll believe it's so great when Qt Creator is implemented fully in QML. Oh wait, that's not going to happen as they admitted they will only be using it very sparingly. Since they don't eat their own dog food, I don't buy the hype.
So if QML is so great why do the Qt Creator guys admit they will barely be using it in the Qt5 version of Qt Creator? The reason is is because it doesn't provide nearly the benefit that is claimed otherwise they'd be pressing full on into QML.
Lots of people care about the RIAA, want it gone, and refuse to buy music.
And by "lots of people" you mean "lots of people in your niche group". How many average people in Best Buy who are buying CDs give a rats ass or even have likely ever heard of the RIAA?
Of course there is a price. I'm just saying I don't agree with the price as it currently is and so I refuse to purchase it.
So you're fine with your boss deciding they don't agree with your salary and will refuse to pay you for your work?
Yes, the most non-biased source of information is an employee of the company who originated the technology and was a founding member of the standardization group.
It's not even technically true since the Canvas 3D that became standardized as WebGL was originally created and implemented by Mozilla.
Is it?
Yes. There are still tons of videos that still are only available in the old Sorenson video codec served up through flash.
WebGL grew out of the Canvas 3D experiments started by Vladimir Vukievi at Mozilla. Vukievi first demonstrated a Canvas 3D prototype in 2006. By the end of 2007, both Mozilla[6] and Opera[7] had made their own separate implementations.
In early 2009 Mozilla and Khronos started the WebGL Working Group.
Sorry, what eventually became WebGL originated from Mozilla and then later Mozilla and Khronos started the working group to standardize it. So yes, you can say it originated from them.
Sued for running a computer simulation of administering the drugs?
Jerry Lewis is MS not Cystic Fibrosis.
Yes. Have you heard about this new service called "iTunes"? I hear Apple thinks it'll be successful in a few years.
That's not a web standards issue.
Except for when that standard relies heavily on those very same video drivers just to work?
Yes, because the place to get a neutral opinion is someone who works for the company who was the originator of WebGL. Gee, no conflict of interest there...
Don't worry, just like with the previous story they'll just claim it wasn't a flaw in Chrome (despite it bypassing the Chrome sandbox) and downplay it.
Sure as long as you ignore the fact that the vast majority of the content on Youtube is still exclusively only served via flash.
go whine about real security problems. this is not one of them.
I seem to remember Microsoft telling us the same thing about ActiveX...
This just in: Guy who works for Mozilla downplays issues in a standard originating from Mozilla.
Sure, but you
Porting a QWidget to QDeclarativeItem is so easy that it could be considered a janitorial task in many projects.
Well then why haven't you ported all the QWidgets over for us by now? It's so quick and easy, right?
Plenty of simple custom QWidgets can be reimplemented in QML with a significant drop in code size, so there's actually a good reason to do that.
That's great if all you ever used were "simple" QWidgets. Many people rely on much more than "simple" widgets for real apps.
The current implementation surely has performance corner-cases, just like early Qt 4.x series had, especially before 4.4.
Thus making it unusable for people who need high performing apps. Most people aren't going to rewrite things in QML just because they are promised that years down the line it will stop being laggier and slower than their current QWidget-based programs.
The performance issues will be worked out, there's no fundamental reason why QML should perform worse than a QWidget-based ui.
Sure, if we ignore the overhead over interpreted code.
Heck, I've found quite a few cases where QLayout-based UIs were stuttering when you resized the windows or dragged splitters
And you've reported these issues?
the QLayout/QWidget infrastructure is seriously broken if you use native widgets, like you had to on OS X for example until very recently.
In what way?
The "distro" would be whatever Google's internel fork of the linux kernel used on their servers is.
How could Yahoo use Linux while not violating this patent?
Because the kernel they use doesn't have the code in it that was the issue?
They likely used a standard kernel (either stock or from a distro) that likely included the "offending feature".
It is highly unlikely that they use a standard kernel.
If by "runs native" you mean it has in the last couple of years moved to use the native drawing APIs of the platform, yes, but it doesn't use the native widgets if that is what you are trying to imply. And for the longest time Qt just faked the native look with themes before using the native drawing APIs.
Qt doesn't use native widgets. They never have. What they have recently changed is using the native drawing APIs. That is not the same thing.
I think you didn't look at the code. First of all, QML is NOT Javascript. It is a declarative language that integrates seamlessly with Javascript.
More accurately, QML is Javascript with extensions.
As for efficiency: I'd beg to differ. There's nothing inherent in the declarative framework that would make it less efficient than QWidget.
And yet with a simple search of "QML slow" you can find all sorts of examples of QML running slow. All sorts of people are seeing lagginess, etc in QML apps. The best the Qt people have shown have been little toy examples where there may be no noticeable difference. Get back to me when they have a full blown app that has lots of intensive visualization and show me that it has no efficieny issues.
QML has expressive power that makes legacy frameworks look almost silly.
Examples? It really means little to hear people throw out buzzwords and provide no examples of how it is more this or that.