When Should I Start Learning GUI Programming?

[Liuqahs15]

Hello, all.

I've been programming for about three months now. I spent my first month-and-a-half learning C++ and JavaScript. JS lightly introduced me to OOP, so I used that mostly, but now I've decided to turn to C++ for a while. So far I've got a pretty moderate understanding of classes, but the things I'm learning feel too complex for command-line programs, so I thought I'd start learning GUI to have an easier time learning things like the STL and whatnot.

My question is, am I going too fast? I tried Win32 API for a few weeks, but that was a punishing experience in poor documentation. I'm currently learning Qt, but its documentation seems to be written for highly experienced programmers. Am I jumping the gun?

[TheMassiveChipmunk]

I would guess you have to learn the basics at least. And then when you feel that you are ready then you can start learning GUI. I started learning GUI a couple months ago and it was not as hard as I thought it would be. But as seeing that you started learning GUI already then I guess it would be alright to keep on learning GUI.
I hope this answer is not confusing.
Have fun :)

[andywestken]

but the things I'm learning feel too complex for command-line programs

Out of interest, what sort of things are you referring to here?

Andy

[Liuqahs15]

things like dynamic memory and overloading operators. You might think it's just a deficiency on my part, but I can't think of any command-line programs where I'll need such insane complexity.

[shacktar]

What if you need to create an array based on a length given by the user?

[Liuqahs15]

That would be an example of a situation where dynamic memory would be necessary, but it's so straightforward and boring. It's more of an isolated scenario than a program. I've learned the most from writing programs that drew on multiple features of the language, with multiple solutions. It lets me experiment and make mistakes and learn things the tutorials didn't say.

What would I gain by writing something like this:

cout << "How many empty spots do you need?";

cin >> x;

int * Spots = new int [x];

Or something roughly similar. I can't be arsed to check if that's syntactically sound, you get the picture.

[andywestken]

I think you are probably jumping the gun a little bit. But it doesn't mean you shouldn't have a look at GUI programming. Have you had a look for a friendlier Qt tutorial? If you're talking about the API docs themselves, they are prob. targetted at (impatient) experienced programmers!

If you wanted to learn Windows GUI programming, I'd point you at Petzold's book (Programming Windows). But I don't know the Qt equivalent.

I'm not sure GUI programming is any easier than STL. Or is going to help you with STL (not sure I understood you here?). I think the problem with GUI program -- at least in the Windows world -- is there are lots of almost random little bits and pieces to learn about before you can really get to grips with the subject, to the extent that you spend more time on the actual problem than hunting for the right bits of into (overstating, but...).

On the other hand, basic drawing and message handling is relatively easy, API documentation aside. So writing an application that can open and view a file, allow users to click on buttons, display menus, etc. would be an achievable target. But it doesn't merit heavy use of dynamic memory or overloading operators either.

Not sure how good the idea is, but one -- console based -- problem what could involve both dynamic memory and overloading operators, as well as polymorphism, is a schema specific C++ class-based XML parser. It would need to be efficient to load files in a timely manner.

You could either write the code from the ground up, if you were ultra keen, or start off using a steam-based parser (e.g. Expat/ExpatPP), if you'd rather focus on the classes, etc (rather than iostream).

One possible schema to use is a subset of SVG. It's quite involved, but if you limit yourself to basic shapes, lines, and text, it should be straight forward enough.

Then, when you get it working, you could go on to write a little GUI app which uses the sae parser classes to load the SVG and display it. And would require all the basic functionality of you typical GUI app as listed above.

While it is "reinventing the wheel", I think re-implementing functionality is a useful learning exercise. You would even be able to compare your app against (e.g. Adobe SVG renderer in IE or Firefox's native capability).

It is a good evercise in abstracting the UI from the model; you should be able to unplug the xml handling code from the command line app and plug it into the GUI app without having to change it!!

Andy

[Danny Toledo]

Wasn't C++ designed for the console? I remember reading somewhere (I haven't an idea as to where, so credibility is down to the people here who can either confirm, deny or ignore me) that Windows API is written in C. So really, you would have to learn C (unless you want to go to a media library).

Back to C++, I'm not 100% sure, but I think that it is indeed designed (written around) the console. Therefore the STL would be for console applications. However, there are media libraries which were written in C++ and (make) use (of) the STL. Having a (even slight) background with such things will make the process a little faster, but jumping right into it isn't out of the question (if I misinterpreted the following article properly):

http://cplusplus.com/articles/G13hAqkS/

It's geared more towards game development, but the general idea is (almost) the same,

Disch wrote:

Remember they're different worlds, and having some experience in one doesn't necessariliy prepare you for the other

Doubt it helped any (probably more confusing than anything), but I thought I'd throw my pennies worth in.