You don't just #include and magically get shit that can go onto silicon

I never said so. The fact that is a dialect of C++, not pure C++, speaks volumes already.

Why not? There is SystemC, a dialect of C++ which can be implemented in hardware (FPGA, for instance). What Algotochip is claiming is just one little more step forward.

The reason Qt 4.4+ applications do not work with AutoIt, or any other WinSpy-like application, is the so-called "alien widgets":

http://labs.qt.nokia.com/2007/08/09/qt-invaded-by-aliens-the-end-of-all-flicker/

The normal behavior of an application is to create a Window object for every widget (window, button, combobox, etc) on screen. Usually that is done at the very low level, therefore most users (and even developers) do not know about it. This is true for every platform I know: Windows, X11 and Mac. I don't know the details about Wayland but I would be surprised if Wayland used a different approach.

The problem with the 1-window-per-widget approach is it causes a lot of unnecessary refreshes, which lead to flickering and a low performance over remote access protocols such as Remote Desktop, Citrix, etc. The reason is the graphics layer (GDI, X11, Quartz, etc) is responsible for refreshing the widgets and it will refresh the full widget even if only one pixel changed, or even if it didn't change at all and it was only the parent widget which changed.

Since version 4.4, Qt takes a new approach: create ONE (and only one) top level window for the application, then simulate all the other widgets by "drawing" them on screen. This allows the Qt painting system to have a finer-grained control over what needs to be repainted and translates into no flickering without the need for double-buffering.

Given that AutoIt is expecting full-fledged Window objects, it will fail with any application using Qt 4.4 because there is only ONE Window object.

Now that we know why AutoIt fails, we can try to find out what needs to be done.

The first approach is to just tell Qt to use native widgets, i. e. 1-window-per-widget. The Qt documentation, which you have not read, explains how to do this:

http://qt-project.org/doc/qt-4.8/qwidget.html#native-widgets-vs-alien-widgets

As you are very lazy, let me summarize that for you: set the QT_USE_NATIVE_WINDOWS environment variable to 1 and now you can use AutoIt. Performance will degrate a bit, though.

The proper approach, which needs to be implemented in AutoIt, would be to hook into the Qt painting system and "learn" about the internal representation of the emulated Window objects. That way AutoIt would be able to automate any Qt application, not matter if QT_USE_NATIVE_WINDOWS is used or not. This is what GUI testing automation tools such as TestComplete, Squish and others do: toolkit-specific plugins for Qt, Gtk, WPF, DevExpress, Telerik, etc.

That's of course only true for applications using QWidgets. For applications using Qt Quick, there is nothing like QT_USE_NATIVE_WINDOWS and the only possible approach is to create a toolkit-specific approach.

Desktop Linux will be a reality when people have a reason to choose Linux over Mac and Windows.

Let's assume all the eye-candy, hardware support, etc is there.

There is also a lot of good applications, yet people want more. Desktop Linux needs closed source shareware, freeware, etc applications. Not because there is no open source alternative but because people want to have 10,000 applications to choose from instead of 10. Also, by having shareware on Linux, those microISVs will be promoting Linux amongst their customers, which will in turn make Linux more popular.

So what do we not have shareware, freeware and other closed-source applications on Linux? Because of binary compatibility. When an ISV wants to release an application for Linux, he has to test with a gazillion Linux distributions, do all kind of tricks and ship his own version of every dependency down to glibc (it's a nightmare even with Listaller!), explain how the average Joe -who knows nothing about root, package managers, etc- can install it on Linux, etc Just not worth it.

Can we solve that? Sure we can. Canonical started by offering the "partner" closed-source repository but it's not exactly successful. There are very few closed-source applications there. What we need is a single appstore for all the distributions. Intel AppUp looks like a good start but again it's not popular. It will never be unless we solve the binary compatibility issues.

Please do not answer with "but closed source does away with my freedom", etc. 99% of the people do not care. Even slashdotters. Android Market, the Apple AppStore, the Kindle, etc show even most of those who boast about software freedom are carrying a Kindle and an iPhone, which are the epitome of closed-sourceness.

I said that one year ago:

A wish a day 7: make emerge a generic package manager for Windows
A wish a day 6: AppStore-like installer for KDE on Windows

Intel AppUp includes open source software but it's not *only* open source.

It's sad how open source and Linux distributions failed to capitalize on this appstore-frenzy.

I think scorp1us and I might be the only /.ers to have ever used witty?

I too use Wt (I'm the Debian packager)

Are you sure you are not confusing Wt with something else? Wt works with 2 MB of RAM.

http://redmine.webtoolkit.eu/projects/wt/wiki/Wt_embedded

Wt is the best one I have tried. I use the C++ version, although there is also a Java version (JWt).

What makes Wt unique is its approach: widgets. You develop web applications like you were developing desktop applications. Also, the API is Qt-like (but using Boost).

I gave up on Rails after I used Wt.

Want a virtualization console? Take Wt, libvirt and an HTML5 VNC client and you are done.

Need Active Directory authentication? Wt, Samba (or Windows APIs if you are on Windows), done.

Streaming? Wt, ffmpeg libraries, done.

Forgetting about bindings and being able to use the millions of C/C++ libraries out there was a huge relief.

Also, size: Rails, Django (and even PHP) just do not fit in an embedded environment. Wt does.

That depends on the impact that the frontend has on the whole system; if it's small, 9 hours optimizing the Python code might be more valuable than 90 learning C++ and a new framework.

The opposite is also true: being a C++ developer, I'd rather go with Wt than (re-) learn Rails, PHP or Django.

Also, size: Rails, Django (and even PHP) just do not fit in an embedded environment. Wt does.

Sorry but no. With ASP.NET you still have the concept of page, session, etc very very present. With Wt, you don't. It makes a huge difference.

Wt is the best one I have tried. I use the C++ version, although there is also a Java version (JWt).

What makes Wt unique is its approach: widgets. You develop web applications like you were developing desktop applications. Also, the API is Qt-like (but using Boost).

I gave up on Rails after I used Wt.

Want a virtualization console? Take Wt, libvirt and an HTML5 VNC client and you are done.

Need Active Directory authentication? Wt, Samba (or Windows APIs if you are on Windows), done.

Streaming? Wt, ffmpeg libraries, done.

Forgetting about bindings and being able to use the millions of C/C++ libraries out there was a huge relief.

Obligatory reference to the Sokal Affair.

The Sokal affair, also known as the Sokal hoax,[1] was a publishing hoax perpetrated by Alan Sokal, a physics professor at New York University. In 1996, Sokal submitted an article to Social Text, an academic journal of postmodern cultural studies. The submission was an experiment to test the publication's intellectual rigor and, specifically, to learn if such a journal would "publish an article liberally salted with nonsense if it (a) sounded good and (b) flattered the editors' ideological preconceptions."

Have you even looked in a dictionary? No, of course you have not!

> Wrong, punta is whore in spanish.

You meant "puta", not "punta". Like in English (bitch, whore, etc), there are many words in Spanish for that.

The "intelligent, vivacious woman" meaning is not in any dictionary. Not even in the Spanish Language Thesaurus!