Exercise 04 - gtk+

1. gtk+ is a widget library with a C interface. Most of the work of this exercise is to start understanding gtk+ by reading parts of its documentation and modifying code we provide.
2. gtk+ documentation is available here. I'd read the Getting Started with GTK+ section, up through Opening Files. (No files in this exercise, but we'll eventually use them.) There is also per-widget reference information which you will likely want to consult.
3. We provide code that creates a main window with a single quit button. You extend the implementation to display an additional button that shows an image, with the images displayed being rotating each time the button is clicked.

   Before

   After

4. While we still want no memory leaks, finding them with valgrind in a gtk+ program is a nightmare, because gtk+ does not itself clean up. Our rule is that your code should have no leaks that involve just your code. That's vague, and there are sure to be questions about just what it means later, but operationally it means essentially that if a TA could fix your leak in 10 minutes or so of debugging, then you should have fixed it. If after 10 minutes it appears that fixing it would require modifying gtk+, then you're not expected to fix it.

5. We provide a single source file, a makefile, and some sample images. We also provide a solution executable that relies on image files a.jpg, b.jpg, and c.jpg. (If you get tired of seeing our images, you can replace them with your own, but those file names must be preserved.)

6. The distribution is here.

7. It is common to see accessibility bus warnings when launching the program.

• Your ex04.c file. It must build when we say 'make'. If doing so required you to modify our makefile, then turn in your makefile as well.

Your code must:

• compile on attu without errors or warnings

• have no crashes, memory leaks (under our revised definition), or memory errors

• be pretty: the code and its formatting, modularization, variable and function names, and so on, must make us smile rather than cry.

• be robust: you should think about handling bogus input from the user, and you should handle hard-to-handle cases (if there are any) gracefully.