Slashdot Mirror

It's actually one feature that I'm surprised is not pervasive yet. Search over all commands in the application is extremely useful, especially for the more complicated suites like Office or VS.

It's slowly trickling down elsewhere - e.g. we've added something like it in VS11 (with more filtering features, but that's feasible because it's a product for developers who can handle and appreciate that complexity), and, I believe, most Java IDEs have had similar for a while now. But why not e.g. add it to the standard Win32 menu control? Or, in frameworks which have UI actions as first-class entities regardless of their placement (e.g. WPF commands, or Qt actions), provide a stock widget to search through all actions available in the current context.

I recommend he learn some well established api. He should get straight into it. Something graphical with very intense visual feedback. He should start by just getting the demos to work. They are *really* simple to get setup, and give great insight in to the capabilities of the frameworks. Then as he progresses he will learn other things he can accomplish and add to them. http://code.google.com/more/ http://developers.facebook.com/ http://qt-project.org/ https://developer.apple.com/library/ios

As a base. he would need javascript (w3schools), or python (Python: Essential Rererence), or C (Programming in C), or C++ (Programming: Principles and Practises Using C++). He does not need to read these books. He just needs to reference them. All the information in them is available online, but having a physical reference is always great to have within reaching distance.

When I was a kid, I would only read a book if I knew it contained the solution to a problem. I would read the book cover to cover if I had to, but in general, I was always more interested in building rather than reading.

My only intent was to play video games, and I would do anything to get them to work. I would save every penny just to by another mb of ram. I was constantly changing the motherboards and processors as well. When I was 11, I was writing batch scripts. At that time, I was using 80386 architecture and DOS. I moved to windows to play games like ski-free, and to play around with winsock and tcp. I got into irc for videos and music, which also introduced me the concept of a newsgroup. At this point everything changed. Any problem I had could be solved with ease. Generally, somebody else would always have faced the same problem I had, and they had solutions!

I got into web development pretty early, but I got bored with it quickly, since at that time, the specification was pretty limited, and I was always more interested in playing video games and sports instead. I'm 29 now, and I have a bachelors in computer science, and a masters in engineering. I do numerical programming with C++ and OpenCL.

I only got into hardcore programming in university, but my general experience with computing placed me highly with my peers. My university was arguably the best in the country for that particular undergraduate program. Lots of my friends had fathers who were programmers, and taught them a lot at a young age, but none of them progressed faster than I did. I easily caught up to them.

My point is that you do not need to push him into programming, He may loose interest very quickly. My interest in things has always been very volatile, since there are so many other things to be interested in as well (sports, music, novels, etc). If his passion is genuine, he can catch up easily. The one corollary is that each generation is exponentially more intelligent than the previous generation. My generation was the first to have access to an over abundance of information. Before, there was a deficit of information and a surplus of attention, but now there is a surplus of information, and a deficit of attention. Access to such an infinite pool of information has made me much more ingenuous than my father's generation. Our kids will most likely be exponentially smarter than we are. Of course, previous generations more easily focused on one particular field, which had its merits, as they made incredible discoveries. The argument that there are less things to discover now is bulls$%*. We still understand very little in the scope of things. He does need to become the next teenage billionaire. His passion(s) just need to be nurtured properly. LET HIM PLAY! He has to work for the rest of his life.

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.

Less than a minute of Googling later: Qt Designer's UI File Format

Your counter-example to my point uses an XML-based declarative UI file format with a strict validating schema.

I'm not sure what you mean by Interface Builder you mean the Apple tool, which uses .NIB or XIB files. Those formats are -- if anything -- closer to XAML than even the QT format, as they contain XML representations of the GUI document object model.

As far as I can see, neither format supports imperative concepts such as loops or other control flow.

Qt isn't going for web apps.

http://qt-project.org/wiki/Qt_for_Google_Native_Client

They've made an effort over the past year to move Qt into becoming an independent project. See http://qt-project.org/ and http://wiki.qt-project.org/The_Qt_Governance_Model . In some respects, Nokia's already put all their eggs in Microsoft's basket (their abandoning of Meego and non Windows Phone mobile OSs), and it doesn't seem to have impacted Qt's development in any noticeable fashion.

They've made an effort over the past year to move Qt into becoming an independent project. See http://qt-project.org/ and http://wiki.qt-project.org/The_Qt_Governance_Model . In some respects, Nokia's already put all their eggs in Microsoft's basket (their abandoning of Meego and non Windows Phone mobile OSs), and it doesn't seem to have impacted Qt's development in any noticeable fashion.

Bad for the open source community and for software in general - http://lists.qt-project.org/pipermail/development/2011-December/000908.html "So now there is total of 108 improvements and bug fixes available in Qt Commercial 4.8.0 that are not part of the LGPL release"