Well said. But we have to start the adventure of learning somewhere.

There is a zen saying (paraphrased) about the stages of learning.
1. Those who do not know that they do not know.
2. Those who do know that they do not know.
3. Those who do know that they do know.
4. Those who do not know that they do know.

Level 1 people are unaware of the existance, importance or size of a field.
Level 2 people are aware of the field but do not have standalone competence.
Level 3 people have reached good proficiency and are suited to teaching 1's & 2's.
Level 4 people have reached the highest guru levels and can only teach 3's. They automatically correctly perform level 2 stuff at an intuitive level and have forgotten what it was like.

I am at approx. Level 2.4 on Qt/C++/Linux and trying to raise that to Level 3. I think should be attainable if I spend a year of evenings at it reading everything I can get my lunch-hooks on and trying to think in C++. So where better to start than The Correct C++ Tutorial for Qt4?

I understand the difficulty of writing doc's. I've done a few. After completing a complex project one stumbles gasping across the line while offering the project disk with quivering outstretched hand, to be asked "OK, now what about the user manual?". It's not easy to summon the same level of energy for it. Unpaid, even a saint finds it taxing.

As to the level of audience to pitch a tutorial lesson series at, I imagine that only the first lesson would need to cover low level stuff like "click the third button" along with an explanatory paragraph. Once the user has identified the button and understands why it was to be clicked, subsequent lessons can pass lightly over this detail. The art is to make each step of the staircase of a climbable size, with no omitted or cracked treads.

I guess traditional lecturer/student arrangements have the advantage that the student can ask for clarification as needed. Uncertainty need gnaw for only seconds rather than days and the lecturer can revise the lesson for next term's students. This arrangement is expensive of course. Books and web resources are cheaper but require more dedication from the student.

A typical scenario:
- User decides "I need to display a string on the screen".
The book then sez:
- For simple strings which do not change much in length, use a Label. To read, write or reposition the label the useful setters and getters are... . For more elaborate features like font changes or controlling visibility refer to QLabel in...
- For strings which may change significantly in length or require direct user input use a QEditLine. An example may be found at... The string is stored internally as.. and may be manipulated with the normal functions for that class such as... .
- For multi-line text use a .... Examples can be found at... and so on.

Much of this info is in the class description notes, but one needs to somehow know which class is likely to be the goldmine. This is not as easy as it might sound. A list of hundreds of classes, many of which can require over an hour of reading, presents a formidable task if you are not familiar with them. A single paragraph could over come this. Quite often only a combination of classes is meaningful, such as a canvas and canvas view or a pixmap and painter. A means of mapping typical tasks to likely candidate classes would be really really good. Really. Good.

Anyway, it is time for me to get on with the tutorial. I still think it's aimed about right, it explained a few points which had nagged me for weeks. They were points to which I could find no reference to in the large amount of Qt docs I have hunted through. With the work already done by Johan Thelin and suggestions from any/all of us, it could become a significant Qt guide. It is needed for those who follow.

Thank you all for your contributions. It's still fun.