and if your standing near a particle emiter - such as a cell phone - you should wear proper shielding as well then right? if one lucky photon can on the off chance give you "cancer" what's the likely hood that prolonged exposure to radiation at a similiar frequency won't get you "lucky" again. really?
xT, a cell phone is a "particle" emitter inasmuch as it emits photons. The use of the word "particle" or "photon" here is pretty much devoid of information. You need to specify what is the wavelength and energy density. Snookums's point flew right over your head. WHOOOSH, hear that?
A cell phone emits electromagnetic radiation that causes our body to heat up and nothing else. It has no potential of causing anything else, and snookums has explained why. A cell phone does to your body what a heat pack would do.
xT, a GQ link, seriously? I suggest that the "less in the know" try to learn some science precisely to be able to figure out that tinfoilhatnuttery like you're spewing is just counterproductive.
Banning life when there is no (or not enough) data to be certain of anything is a good precaution. Who knows how many idiots out there are alive, potentially setting us up for prolonged suffering. Let's nuke the whole planet, just to be sure.
This solves nothing. Dan Abelow could hire a third party as a licensing subcontractor. The outcome could be financially exactly same -- after all, will you now start policing how people write contracts? They could agree to whatever, including a "hiring bonus" paid to him upon execution of contract.
You're twisting my words. I only claim that if you want to get most bang for the buck and have to run any appreciable length of cable to your speaker, use a surplus twisted pair ribbon. RFI-wise it's the next best thing to having a fully shielded cable, and it also has the lowest possible inductance that you can get without resorting to impractical things (impedance matching with a speaker, haha). I stand by this statement. People often run silly stuff like a pair of #18 "speaker wire" between their amp and the speaker, and that's just sad.
IMHO nothing beats running a 36 or more conductor twisted-pair 0.05" pitch ribbon cable between your amp and the speakers. Such cable can be often cheaply bought on eBay as products move to smaller pitch or flat assemblies. 3M makes this stuff, others surely do too. Just connect all odd conductors to one terminal, even conductors to the other. The thing has lowest distributed inductance of anything you could economically use to drive speakers, and it dissipates heat very well, too. The slight distributed series resistance helps, too. Nothing like a 1000ft "open box" of 3M twisted pair ribbon:)
Direct porting to QML means that the code still stays in C++. One could start porting QWidgets by designing a small shim class that interfaces the exposed QWidget API to the underlying QDeclarativeItem APIs. Most of what the shim would do is just translating event data types. I've done it as a proof of concept, and there's nothing to it. You literally derive from a WidgetShim instead of QWidget, and it "just works". There's no difference in performance, since the widget code is exactly same, and the shim is mostly trivial data shuffling stuff. If the widget is referencing any other widgets directly (like view delegates), you have to manually intervene, but for most widgets it's not an issue and a shim class suffices. A cleaner port would mean that you manually or with a code rewriting script change QWidget API calls to QDeclarativeItem ones.
What Nokia wants to do instead is to reimplement all widgets in QML script (not C++), to make them less monolithic and more tweakable, and to interoperate better with rest of QML. This is precisely what the QML Components for Desktop project is all about. I'm sure that whatever bottlenecks or shortcomings are exposed by that project get to influence Qt Quick.
Is there a technological risk in jumping to Qt Quick right away? Sure, it's a new code base and it'd be foolish not to appreciate that mature QWidget code base is almost by definition safer. But with every risk there are rewards, and for my projects Qt Quick is the right choice.
I don't immediately see how typical business applications would suffer at all from Qt Quick: their interfaces are typically quite simple. I'm looking at Apple Mail's main window and it has a toolbar, a treeview sidebar showing the mail folders, another treeview for messages/conversations in the folder, a splitter handle, and the message viewer. There's also a sliding listview for mail activity, and three buttons to control that and a little popup menu.
If we assumed that Apple Mail was written in Qt, and it was done cleanly, then the only major task in porting the main window would be to implement TreeView -- this hasn't been tackled that by the Desktop project. The rest is essentially doing design work: setting up properties for the TreeViews and delegates, and just laying out a couple of widgets. The underlying data models would stay untouched -- again, assuming the work was done right in the first place.
Umm, qmlcreator is implemented in QML. Qt Creator is such a simple thing when it comes to visual design that doing it in QML will not expose any performance issues. It'll still use the same editor widget etc. This actually gives me idea to try it out, I'd love to see the reduction in code size. It may turn out to be a quick job for the main window, too.
It was all self inflicted. The voters let the war spending happen, and they let the TSA happen, and they themselves got terrified of flying. I think we seriously overestimate just what the direct impact of the 9/11 attacks was. All that really happened, and all that really made the difference, was that the U.S. voters' real crummy side got exposed. Noone stood with a gun to people's heads to stop them from flying, or to send troops to Iraq and elsewhere.
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.
Look at any of the demos that come with it. Say the corkboard. Then implement using "bare" Qt.
I have ported a database-driven application to QML, and I can't feel any speed difference between the declarative UI rendering the views and the QWidget views. There are perhaps problems when too many things are moving about at once, but I'm not trying to do that. The only motion is in following the mouse and doing flicks, and this performs as it should.
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.
There's no "interpreted code" anywhere in QML. Whatever parsing there is, is done only once. Javascript is executed by a decently performing JIT-ting runtime -- same one that powers WebKit. Instantiating a QML element does not AFAIK cause any textual source code to be parsed or JIT-ted more than once. Surely there will be some overhead due to parsing QML at application startup, but this can be tweaked by doing lazy instantiation via the Loader.
It's not even about template metaprogramming. Template metaprogramming simply does not provide several facilities that are make-or-break for language binding generation. C++ does not have built-in facilities needed by binding generators, this has nothing to do with Troltech/Nokia's developers "ineptness". Guess why swig still exists? Hint: because whoever designs C++ lives on a little cloud-9 where you don't interface with anybody who doesn't use C++. It's a basic deficiency of current C++ spec, and there's no way around it other than running a code generator external to the compiler.
C++ simply does not provide the introspection needed for a major application development framework. If it did, you could drop MOC. The way it stands, moc basically generates introspection tables because the out-of-touch [expletive deleted] folks who design C++ couldn't be bothered. That's my take on it.
Every time you interface C++ code with any sort of an interpreted or JIT-ed language, you have to generate "bindings" using an external tool precisely because C++ lacks facilities for code to know about other code. Qt folks were nice enough to maintain such a tool themselves and to make it a core part of their process. I don't consider it a bad thing. QMetaObject system makes it fairly easy to expose QObjects to any other language that's either interpreted or JIT-ed.
It doesn't "fake" the look. It uses the visuals drawn by native APIs on both Windows XP and up, and on OS X. You can't enable an OS X look in KDE simply because Qt doesn't have the code that implements the look, it politely asks the Cocoa or Carbon API to do the drawing for it.
Use of native controls is something I shun because as soon as you get a lot of them, you run into serious performance issues. Try having a thousand native-widget OS X buttons in your window, and see how fast they respond. By dropping the native widgets and using a so called alien, styled widget, Qt actually provides better performance than underlying OS X APIs, who'd have thought.
Porting a QWidget to QDeclarativeItem is so easy that it could be considered a janitorial task in many projects. 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. Especially if you have a designer on staff who got Qt Quick training and can provide you with an "endless stream" of custom, appealing widgetry.
There's nothing architecturally wrong with QML. The current implementation surely has performance corner-cases, just like early Qt 4.x series had, especially before 4.4. The performance issues will be worked out, there's no fundamental reason why QML should perform worse than a QWidget-based ui. Heck, I've found quite a few cases where QLayout-based UIs were stuttering when you resized the windows or dragged splitters -- the QLayout/QWidget infrastructure is seriously broken if you use native widgets, like you had to on OS X for example until very recently.
First of all, reimplementing most if not all Qt widgets in QML takes less code than original Qt widget implementations took, line-wise. And it's by a fairly large factor -- a reduction of 5-10 times. Just look at the Qt Quick Components for Desktop -- it's pretty amazing stuff when you realize that a table view is about 500 lines long. For your reference, src/gui/itemviews/qtableview.cpp is 3000 lines long, and it's not nearly as modular and tweakable as TableView QML element.
The beauty and power of QML is shown in the fact that the TableView component's source code is not only fairly easy to understand, but it's very easy to tweak. I had to add per-column delegates for my project and it was a dozen lines or so, took about an hour without any prior QML experience. Good luck with modifying qtableview.cpp. Now I of course realize that there's no full feature parity between the two just yet, but they are alarmingly close. And if you consider source tweakability to be a feature in itself, I think that QML already wins over native Qt views. Even little details make life easier: suppose you want to tweak QTableView and cannot simply derive from it, but you have to modify the source. If you want to copy it over to your own project, you have to at least do a search-and-replace to change the damned class name everywhere. In QML, you change the damn file name and you're done. Add enough of those "little" improvements, and you get something that beats expressibility of C++ by a lot.
Qt could have been much further ahead if they implemented the QML idea back in times of Qt 1.x... And no, I don't buy the argument that the platforms back then were too slow. They'd have had to spend more effort in optimizing things, but there's nothing inherent in QML that makes it slow. All the heavy lifting is done by C++ code or JIT-ed JavaScript anyway.
Couldn't agree more. I will be getting our designer lady a QML/QMLDesigner tutorial in a week or so. That way I'll be getting ready-made user interfaces, with relevant functionality already built in, and I can focus on providing data models and state management for the application as a whole.
That's a silly argument. I don't think you're laying out all the widgets by hand all the time, right? You're probably using Designer to produce.UI files for most of your UI. Guess what: QML designer is pretty much the same thing, but gives you much more expressive power. The QWidget/QLayout systems has inherent constraints that cannot be worked around by simply expanding the API. They needed a brand-new paradigm, and they delivered.
All of the back-end functionality (models!) has to be done in C++ anyway, and you're free do develop custom visual elements in C++. In fact, you likely will end up developing custom visual stuff in C++ where you had complex QWidgets, but not for "silly" stuff.
So far in Qt you had to pretty much subclass controls or widgets and write C++ code for simple UI elements like toggle switches, gages, indicators, etc. With QML, you can get simple controls without writing any code at all and using QML Designer (a plugin in Qt Creator).
For complex views, like say a PCB layout, electrical schematic or a document editor, you'll still code it in good old C++.
At least QML somewhat forces you to do clean model-view separation -- of course seasoned developers who know their stuff will do it naturally, but there's plenty of code out there where data is intertwined with visuals. I applaud that QML promotes clean separation of concerns here.
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. As for efficiency: I'd beg to differ. There's nothing inherent in the declarative framework that would make it less efficient than QWidget. QML has expressive power that makes legacy frameworks look almost silly. QML comes with a lot of demos. Try implementing some of them using out-of-the-box pre-QML APIs and you'll understand.
The QLayout system is a complete nightmare -- to get anything that's less-than-trivial, you have to relegate to spreasheet layouting: make lots of extra rows and columns, and then span your widgets across several of them. And good luck if your widget needs to have visible elements outside of its boundary -- and no, it's not only about particle effects, how about highlighting, drag-and-drop/drag-and-clone, etc.
I fully believe that legacy UI framework design decisions (ala GTK, Qt, WxWidgets) have seriously and negatively affected usability of common business applications (ERP systems, I'm talking about you). If you want to design clean, usable UIs using a legacy framework, you are pretty much back to using some sort of a hierarchical canvas (like QGraphicsScene) and laying out everything yourself. QML takes a lot of busywork out of that.
and with nuclear power, when you have an accident, it stays with you for centuries. that's the big problem with nuclear power
nuclear power presents longterm effects outside of the realm of mankind's normal psychological considerations
Tell that to archeologists and librarians -- some of them deal with artifacts that make half-life of Cs-137 seem pretty insignificant. If we're supposedly bad at dealing with such timescales, we should have been abandoning this "old crap" left and right, right? I mean, why bother, right?
Your whole argument IMHO falls on its face because the supposed "mankind's normal psychological considerations" are just something you made up. And the "terrible consequences" -- well, you also made those up, because even if you include Chernobyl and Kyshtym, it's about 1/3 the number of yearly road deaths in the U.S. alone, and less than 4x the number of deaths in 9/11 terrorist attacks. It's hardly ground-breaking, so to speak. Yeah, loss of human life is hard. But the supposed value you assign to human life is not corroborated by what the society at large thinks. Per your "logic", road transport falls into same category: it's something we'll be stuck for the foreseeable future (it's a century already!), and the worldwide death toll is comparatively staggering.
There have been plenty of man-made disasters (wars and genocides) that killed a couple orders of magnitude more people. And guess what: wars have long-lasting consequences, too, especially if they enable regimes to dumb down whole countries in 'cleansings', stalling progress for decades. So whatever demonstrated damage has been done by all nuclear disasters in the history, including what we presume will be the outcome of Fukushima (large-scale contamination, keeping 20+km radius from occupation for decades), is fairly insignificant. The cause for scaremongering is in your head, rightfully and regrettably so.
This is hardly a "full-blown" disaster. It's bad, but I believe it's an OK price to pay not to have to have burned all the coal equivalent of those plants' lifetime energy output. There is no risk-free technology. In any risk assessment all you do is reduce risks to an acceptable level. To me, the demonstrated risks of nuclear power are well within the acceptable range. Heck, they seem to be insignificant compared to demonstrated risks from dependency on fossil fuels.
Slashdot Mirror
and if your standing near a particle emiter - such as a cell phone - you should wear proper shielding as well then right? if one lucky photon can on the off chance give you "cancer" what's the likely hood that prolonged exposure to radiation at a similiar frequency won't get you "lucky" again. really?
xT, a cell phone is a "particle" emitter inasmuch as it emits photons. The use of the word "particle" or "photon" here is pretty much devoid of information. You need to specify what is the wavelength and energy density. Snookums's point flew right over your head. WHOOOSH, hear that?
A cell phone emits electromagnetic radiation that causes our body to heat up and nothing else. It has no potential of causing anything else, and snookums has explained why. A cell phone does to your body what a heat pack would do.
xT, a GQ link, seriously? I suggest that the "less in the know" try to learn some science precisely to be able to figure out that tinfoilhatnuttery like you're spewing is just counterproductive.
The human body is also really good at spreading and dissipating excess heat.
-- fact widely used by people tinkering with electronics. Our thumb is a nice, portable, always-on water-cooled heatsink.
Let's start with getting sensible, well trained, responsible adults to teach the kids and to administrate the schools and school districts.
Banning life when there is no (or not enough) data to be certain of anything is a good precaution. Who knows how many idiots out there are alive, potentially setting us up for prolonged suffering. Let's nuke the whole planet, just to be sure.
This solves nothing. Dan Abelow could hire a third party as a licensing subcontractor. The outcome could be financially exactly same -- after all, will you now start policing how people write contracts? They could agree to whatever, including a "hiring bonus" paid to him upon execution of contract.
You're twisting my words. I only claim that if you want to get most bang for the buck and have to run any appreciable length of cable to your speaker, use a surplus twisted pair ribbon. RFI-wise it's the next best thing to having a fully shielded cable, and it also has the lowest possible inductance that you can get without resorting to impractical things (impedance matching with a speaker, haha). I stand by this statement. People often run silly stuff like a pair of #18 "speaker wire" between their amp and the speaker, and that's just sad.
IMHO nothing beats running a 36 or more conductor twisted-pair 0.05" pitch ribbon cable between your amp and the speakers. Such cable can be often cheaply bought on eBay as products move to smaller pitch or flat assemblies. 3M makes this stuff, others surely do too. Just connect all odd conductors to one terminal, even conductors to the other. The thing has lowest distributed inductance of anything you could economically use to drive speakers, and it dissipates heat very well, too. The slight distributed series resistance helps, too. Nothing like a 1000ft "open box" of 3M twisted pair ribbon :)
Direct porting to QML means that the code still stays in C++. One could start porting QWidgets by designing a small shim class that interfaces the exposed QWidget API to the underlying QDeclarativeItem APIs. Most of what the shim would do is just translating event data types. I've done it as a proof of concept, and there's nothing to it. You literally derive from a WidgetShim instead of QWidget, and it "just works". There's no difference in performance, since the widget code is exactly same, and the shim is mostly trivial data shuffling stuff. If the widget is referencing any other widgets directly (like view delegates), you have to manually intervene, but for most widgets it's not an issue and a shim class suffices. A cleaner port would mean that you manually or with a code rewriting script change QWidget API calls to QDeclarativeItem ones.
What Nokia wants to do instead is to reimplement all widgets in QML script (not C++), to make them less monolithic and more tweakable, and to interoperate better with rest of QML. This is precisely what the QML Components for Desktop project is all about. I'm sure that whatever bottlenecks or shortcomings are exposed by that project get to influence Qt Quick.
Is there a technological risk in jumping to Qt Quick right away? Sure, it's a new code base and it'd be foolish not to appreciate that mature QWidget code base is almost by definition safer. But with every risk there are rewards, and for my projects Qt Quick is the right choice.
I don't immediately see how typical business applications would suffer at all from Qt Quick: their interfaces are typically quite simple. I'm looking at Apple Mail's main window and it has a toolbar, a treeview sidebar showing the mail folders, another treeview for messages/conversations in the folder, a splitter handle, and the message viewer. There's also a sliding listview for mail activity, and three buttons to control that and a little popup menu.
If we assumed that Apple Mail was written in Qt, and it was done cleanly, then the only major task in porting the main window would be to implement TreeView -- this hasn't been tackled that by the Desktop project. The rest is essentially doing design work: setting up properties for the TreeViews and delegates, and just laying out a couple of widgets. The underlying data models would stay untouched -- again, assuming the work was done right in the first place.
Umm, qmlcreator is implemented in QML. Qt Creator is such a simple thing when it comes to visual design that doing it in QML will not expose any performance issues. It'll still use the same editor widget etc. This actually gives me idea to try it out, I'd love to see the reduction in code size. It may turn out to be a quick job for the main window, too.
It was all self inflicted. The voters let the war spending happen, and they let the TSA happen, and they themselves got terrified of flying. I think we seriously overestimate just what the direct impact of the 9/11 attacks was. All that really happened, and all that really made the difference, was that the U.S. voters' real crummy side got exposed. Noone stood with a gun to people's heads to stop them from flying, or to send troops to Iraq and elsewhere.
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.
Look at any of the demos that come with it. Say the corkboard. Then implement using "bare" Qt.
I have ported a database-driven application to QML, and I can't feel any speed difference between the declarative UI rendering the views and the QWidget views. There are perhaps problems when too many things are moving about at once, but I'm not trying to do that. The only motion is in following the mouse and doing flicks, and this performs as it should.
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.
There's no "interpreted code" anywhere in QML. Whatever parsing there is, is done only once. Javascript is executed by a decently performing JIT-ting runtime -- same one that powers WebKit. Instantiating a QML element does not AFAIK cause any textual source code to be parsed or JIT-ted more than once. Surely there will be some overhead due to parsing QML at application startup, but this can be tweaked by doing lazy instantiation via the Loader.
It's not even about template metaprogramming. Template metaprogramming simply does not provide several facilities that are make-or-break for language binding generation. C++ does not have built-in facilities needed by binding generators, this has nothing to do with Troltech/Nokia's developers "ineptness". Guess why swig still exists? Hint: because whoever designs C++ lives on a little cloud-9 where you don't interface with anybody who doesn't use C++. It's a basic deficiency of current C++ spec, and there's no way around it other than running a code generator external to the compiler.
C++ simply does not provide the introspection needed for a major application development framework. If it did, you could drop MOC. The way it stands, moc basically generates introspection tables because the out-of-touch [expletive deleted] folks who design C++ couldn't be bothered. That's my take on it.
Every time you interface C++ code with any sort of an interpreted or JIT-ed language, you have to generate "bindings" using an external tool precisely because C++ lacks facilities for code to know about other code. Qt folks were nice enough to maintain such a tool themselves and to make it a core part of their process. I don't consider it a bad thing. QMetaObject system makes it fairly easy to expose QObjects to any other language that's either interpreted or JIT-ed.
It doesn't "fake" the look. It uses the visuals drawn by native APIs on both Windows XP and up, and on OS X. You can't enable an OS X look in KDE simply because Qt doesn't have the code that implements the look, it politely asks the Cocoa or Carbon API to do the drawing for it.
Use of native controls is something I shun because as soon as you get a lot of them, you run into serious performance issues. Try having a thousand native-widget OS X buttons in your window, and see how fast they respond. By dropping the native widgets and using a so called alien, styled widget, Qt actually provides better performance than underlying OS X APIs, who'd have thought.
Porting a QWidget to QDeclarativeItem is so easy that it could be considered a janitorial task in many projects. 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. Especially if you have a designer on staff who got Qt Quick training and can provide you with an "endless stream" of custom, appealing widgetry.
There's nothing architecturally wrong with QML. The current implementation surely has performance corner-cases, just like early Qt 4.x series had, especially before 4.4. The performance issues will be worked out, there's no fundamental reason why QML should perform worse than a QWidget-based ui. Heck, I've found quite a few cases where QLayout-based UIs were stuttering when you resized the windows or dragged splitters -- the QLayout/QWidget infrastructure is seriously broken if you use native widgets, like you had to on OS X for example until very recently.
First of all, reimplementing most if not all Qt widgets in QML takes less code than original Qt widget implementations took, line-wise. And it's by a fairly large factor -- a reduction of 5-10 times. Just look at the Qt Quick Components for Desktop -- it's pretty amazing stuff when you realize that a table view is about 500 lines long. For your reference, src/gui/itemviews/qtableview.cpp is 3000 lines long, and it's not nearly as modular and tweakable as TableView QML element.
The beauty and power of QML is shown in the fact that the TableView component's source code is not only fairly easy to understand, but it's very easy to tweak. I had to add per-column delegates for my project and it was a dozen lines or so, took about an hour without any prior QML experience. Good luck with modifying qtableview.cpp. Now I of course realize that there's no full feature parity between the two just yet, but they are alarmingly close. And if you consider source tweakability to be a feature in itself, I think that QML already wins over native Qt views. Even little details make life easier: suppose you want to tweak QTableView and cannot simply derive from it, but you have to modify the source. If you want to copy it over to your own project, you have to at least do a search-and-replace to change the damned class name everywhere. In QML, you change the damn file name and you're done. Add enough of those "little" improvements, and you get something that beats expressibility of C++ by a lot.
Qt could have been much further ahead if they implemented the QML idea back in times of Qt 1.x... And no, I don't buy the argument that the platforms back then were too slow. They'd have had to spend more effort in optimizing things, but there's nothing inherent in QML that makes it slow. All the heavy lifting is done by C++ code or JIT-ed JavaScript anyway.
Couldn't agree more. I will be getting our designer lady a QML/QMLDesigner tutorial in a week or so. That way I'll be getting ready-made user interfaces, with relevant functionality already built in, and I can focus on providing data models and state management for the application as a whole.
That's a silly argument. I don't think you're laying out all the widgets by hand all the time, right? You're probably using Designer to produce .UI files for most of your UI. Guess what: QML designer is pretty much the same thing, but gives you much more expressive power. The QWidget/QLayout systems has inherent constraints that cannot be worked around by simply expanding the API. They needed a brand-new paradigm, and they delivered.
All of the back-end functionality (models!) has to be done in C++ anyway, and you're free do develop custom visual elements in C++. In fact, you likely will end up developing custom visual stuff in C++ where you had complex QWidgets, but not for "silly" stuff.
So far in Qt you had to pretty much subclass controls or widgets and write C++ code for simple UI elements like toggle switches, gages, indicators, etc. With QML, you can get simple controls without writing any code at all and using QML Designer (a plugin in Qt Creator).
For complex views, like say a PCB layout, electrical schematic or a document editor, you'll still code it in good old C++.
At least QML somewhat forces you to do clean model-view separation -- of course seasoned developers who know their stuff will do it naturally, but there's plenty of code out there where data is intertwined with visuals. I applaud that QML promotes clean separation of concerns here.
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. As for efficiency: I'd beg to differ. There's nothing inherent in the declarative framework that would make it less efficient than QWidget. QML has expressive power that makes legacy frameworks look almost silly. QML comes with a lot of demos. Try implementing some of them using out-of-the-box pre-QML APIs and you'll understand.
The QLayout system is a complete nightmare -- to get anything that's less-than-trivial, you have to relegate to spreasheet layouting: make lots of extra rows and columns, and then span your widgets across several of them. And good luck if your widget needs to have visible elements outside of its boundary -- and no, it's not only about particle effects, how about highlighting, drag-and-drop/drag-and-clone, etc.
I fully believe that legacy UI framework design decisions (ala GTK, Qt, WxWidgets) have seriously and negatively affected usability of common business applications (ERP systems, I'm talking about you). If you want to design clean, usable UIs using a legacy framework, you are pretty much back to using some sort of a hierarchical canvas (like QGraphicsScene) and laying out everything yourself. QML takes a lot of busywork out of that.
and with nuclear power, when you have an accident, it stays with you for centuries. that's the big problem with nuclear power
nuclear power presents longterm effects outside of the realm of mankind's normal psychological considerations
Tell that to archeologists and librarians -- some of them deal with artifacts that make half-life of Cs-137 seem pretty insignificant. If we're supposedly bad at dealing with such timescales, we should have been abandoning this "old crap" left and right, right? I mean, why bother, right?
Your whole argument IMHO falls on its face because the supposed "mankind's normal psychological considerations" are just something you made up. And the "terrible consequences" -- well, you also made those up, because even if you include Chernobyl and Kyshtym, it's about 1/3 the number of yearly road deaths in the U.S. alone, and less than 4x the number of deaths in 9/11 terrorist attacks. It's hardly ground-breaking, so to speak. Yeah, loss of human life is hard. But the supposed value you assign to human life is not corroborated by what the society at large thinks. Per your "logic", road transport falls into same category: it's something we'll be stuck for the foreseeable future (it's a century already!), and the worldwide death toll is comparatively staggering.
There have been plenty of man-made disasters (wars and genocides) that killed a couple orders of magnitude more people. And guess what: wars have long-lasting consequences, too, especially if they enable regimes to dumb down whole countries in 'cleansings', stalling progress for decades. So whatever demonstrated damage has been done by all nuclear disasters in the history, including what we presume will be the outcome of Fukushima (large-scale contamination, keeping 20+km radius from occupation for decades), is fairly insignificant. The cause for scaremongering is in your head, rightfully and regrettably so.
This is hardly a "full-blown" disaster. It's bad, but I believe it's an OK price to pay not to have to have burned all the coal equivalent of those plants' lifetime energy output. There is no risk-free technology. In any risk assessment all you do is reduce risks to an acceptable level. To me, the demonstrated risks of nuclear power are well within the acceptable range. Heck, they seem to be insignificant compared to demonstrated risks from dependency on fossil fuels.
SSH, gcc, vim, Emacs in javascript?
If the direction where browsers are moving towards is any indication, your statement technically could be rephrased as
SSH, gcc, vim, Emacs running on CLR/JVM/insert your fave jit platform here
Javascript is just a language. The pudding is the virtual machine that runs it, and that VM has been improving by leaps and bounds.
Yeah, because disk access should block all applications, right? You've been very, very lucky or you just romanticize your experience with Win95.