Where is code file

[jimadamthwaite]

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.

[wysota]

To be honest the best way to learn Qt is to sit down and do something simple with it ("Hello world" is a good thing to start with). Then add something more complex, etc. No tutorials needed. Of course all this applies if one already knows C++.

[jimadamthwaite]

To be honest the best way to learn Qt is to sit down and do something simple with it ("Hello world" is a good thing to start with). Then add something more complex, etc. No tutorials needed. Of course all this applies if one already knows C++.

I've already done a dozen Qt tutes. It mostly make perfect sense to me even though my brain has probably been damaged by assembly programming. I can usually visualise the underlying code & structures and even why it is the way it is. I am happy with signals, slots, inheritance, overloading, and so on. I have already written a few working Qt apps for various things, one of which entailed writing a C interpreter (in C++) for industrial PLC control. I've written graphic packs (point, line, circle, ellipse etc.) in 2650, Z80, 6809 & 68K. I am just having trouble guessing the way it is done in Qt. Throwing a painter at a pixmap does not seem a guessable act.

I often find this level of info is missing, causing long delays while I try to deduce what QThingy might help, or even if one exists. You surely know the problem - e.g. you need to already know that a certain function exists, its name, and the name of the header file to #include. Without already knowing that much the function does not exist in your inner world model and you cannot use it until you stumble upon it. It borders on a philosopy problem. The only way I've found to handle this is to read include files during spare moments.

The current task involves 3D coordinate rotations & translations for navigation, so I want to look at the result as a picture. I've done the cannon tute, the butterflies & a few other QCanvas exercises. I have modified them to satisfy myself about various details. I even have the new app working showing a nice little 3D axis with direction pointers & local horizon. I just wish I could get the canvas view to appear on MY window along with the other widgets instead of appearing in its own unintended window. None of the drawing tutes seem to address this as they do not use the GUI designer.

In those tutes the widgets seem to fall where they may according to rules which I cannot deduce. I must use the GUI designer as I do not know how to force my screen layout to be what I need using size hints & various nudging mechanisms. I would lose all the nice auto-layout springs & things. That's why Trolltech invented the designer. The frustration comes from the inner certainty that the fix will be just a few lines of code, but will take a few days to find.

Ah well, keep plugging.

[e8johan]

What you describe is not exactly a Qt-specific issue. You need to know what to expect when working with any toolkit. If you want a tutorial between the Cannon and the Qt Reference Docs, I would like to recommend the Independent Qt Tutorial. It it I try to demonstrate many of the common Qt classes - including painters, canvases and OpenGL.

As for the painter - pixmap relation when drawing - that is just plain OO. You'll get used to it - I promiss!

[jacek]

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?

The whole year is far too much, you don't have to be a C++ guru, but you must understand how C++ works. Qt is built on top of C++ and there is no way you can grok it without knowing C++. I don't think that there's any on-line tutorial as good as books on C++. My personal favorite is "C++ Primer" by Lippman and Lajoie, but there are other books too.

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.

Yes, but you can search the docs quite easily with Qt Assistant and there is a number of articles that describe Qt's internals and how its classes interact with each other. You can find the whole list here.