Re: Gtk::Button set_image()

[Caroline Kierstead <ctkierst cs uwaterloo ca>]

Daniel Elstner wrote:

> That's because of the static class data here:
>
> > const Glib::RefPtr<Gdk::Pixbuf> DeckGUI::deck[ACE+1][SPADE+1] =
> > {   // Set up NINE of {DIAMOND,CLUB,HEART,SPADE}
> > 	{Gdk::Pixbuf::create_from_file("pixmaps/card_0_0.xpm"), 
> > Gdk::Pixbuf::create_from_file("pixmaps/card_0_1.xpm"),
> [...]
> > 	Gdk::Pixbuf::create_from_file("pixmaps/card_5_2.xpm"), 
> > Gdk::Pixbuf::create_from_file("pixmaps/card_5_3.xpm") }
> > };
>
> The initialization is guaranteed to have been completed by the time
> main() is entered.  That implies it is also guaranteed to execute before
> the Gtk::Main initialization. :-)

Ah, that makes sense.

> You need to create the pixbufs at some point after Gtk::Main has been
> instantiated.
>
> A couple of comments:
>
> > 	// Holds 2-D array of pixmaps so can easily index by Faces and Suit.
> > 	const static Glib::RefPtr<Gdk::Pixbuf> deck[ACE+1][SPADE+1];
> > 	const static Glib::RefPtr<Gdk::Pixbuf> nullCard;                           // 
>
> Yuck.  Putting objects of non-POD type into plain C arrays is almost
> always a bad idea.  It should work in this case, but the static
> initialization won't.  You may want to look at pixbuf-demo in gtkmm for
> an example that creates pixbufs from a static array of filenames.

Is this example-pixbuf.cc? I'm on a Mac, so finding the files that were 
installed takes quite a bit of digging. I may be better off just dowloading the 
tar ball to unpack the examples, I guess.

> > 	const Glib::RefPtr<Gdk::Pixbuf> getCardImage( Faces f, Suits s );
>
> It isn't wrong to return a const value, but pointless in most cases.

Ok. I wasn't sure how restrictive the assignment was, so erred on the side of 
keeping the const.

> > 	// Initialize 4 empty cards and place them in the box.
> > 	for (int i = 0; i < 4; i++ ) {
> > 		card[i] = new Gtk::Image( nullCardPixbuf );
> > 		hbox.add( *card[i] );
> > 	} // for
> [...]
> > OtherWorld::~OtherWorld() {
> > 	for (int i = 0; i < 5; i++ ) delete card[i];
> > } // OtherWorld::~OtherWorld()
>
> You can avoid the manual (and unsafe) memory management by taking
> advantage of container ownership:
>
>     hbox.add(*Gtk::manage(new Gtk::Image(pixbuf)));
>
> This works for all non-toplevel widgets.

Is there a spot with good documentation on the memory manager? There's not much 
in the reference manual. How does this interact with using the remove() call on 
a container? Is there a good way to clear out the contents of box, such as a 
Gtk::HBox?

> > const Glib::RefPtr<Gdk::Pixbuf> DeckGUI::nullCard = 
> > Gdk::Pixbuf::create_from_file("pixmaps/cardback2.xpm");
>
> Any particular reason why you're using the obsolete XPM format?  It
> isn't a big deal, but I suspect you might be using XPM only because it
> used to be the standard image format for X applications, ages ago.

Mostly because I'm doing this tangentially based off of someone else's code 
(undocumented, and in Gtk+), when the course is now in C++, so gtkmm seemed more 
appropriate. Anyways, the old course project used these card pixmaps for the 
images so they're easily available.

What would be a more appropriate format to be using?

> Oh, and please always carbon-copy to the mailing list when you're
> replying.

Ok. Thanks for all of your help!


--
---
Caroline Kierstead, Undergraduate Operations Coordinator
David R. Cheriton School of Computer Science
DC3122 x36226