GTKmm: Beyond the One-Window-Wonders?

Well, I took a couple weeks off from coding to focus entirely on job hunting, getting my GED, and looking at colleges. Now that I can see daylight again, it's time to renew my efforts in learning GTKmm.

I have managed to get a basic window to come up using a glade file, and I know more about connecting signals to handlers, such as the use of sigc::mem_fun() to connect a signal to a member function of a class. I also have managed to convert my program to classes rather than functions. My question now is how to implement a child window, such as an about dialog.

Any suggestions on how to go about handling the UI? Should I implement each child of the main window in a class of it's own? Or should I use one "super-class" to handle everything related to the ui? Is there some other way that would work even better? Any thing to get me beyond the simple "one window wonders" that are ubiquitous in all the few tutorials I've managed to find would be wonderful.

Also, I was wondering if anyone knows of a simple program that uses C++, GTKmm, and Glade that I could obtain the source code for and see how they do it. Maybe by looking at some real code, I could learn a lot more than I would by just trying it outright on my own. It would be nice to have a frame of reference to study and work from, rather than just the (in my opinion) horrid attempt at documentation for gtkmm and my own experimentation which has failed massively where GTKmm and it's documentation is concerned.

Well, I woke up this morning and some stuff just clicked. lol. I've advanced a bit, and learned a few things, but now I'm running into a problem with my about dialog. It was working when I used Gtk::AboutDialog::run(), but that causes the about dialog to put the rest of the program on hold until "close" is clicked. Most programs I've seen that use GTK don't do this, so I tried to modify it to use Gtk::AboutDialog::show() instead. I know I need to connect a handler to Gtk::AboutDialog::signal_response() so that I can close it, but actually doing it is giving me a major WTH moment.

the offending code, essentialy, is this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// these are declared as private in class Main_Window
Gtk::AboutDialog* about_win = 0;
Gtk::MenuItem* help_about = 0;

/* This is in the constructor for Main_Window. I've decided that
 * Main_Window will handle the about dialog on its own, since 
 * it is the only place that it will be called from.
 */
builder->get_widget("about_window", about_win);
builder->get_widget("help_about", help_about);

// This one works.
help_about->signal_activate().connect(sigc::mem_fun(*this, &Main_Window::about_show));
// This one doesn't.
about_win->signal_response().connect(sigc::mem_fun(*this, &Main_Window::about_hide));

Both Main_Window::about_show() and Main_Window::about_hide() are declared public and implemented.

The line that doesn't work is causing
1
2
3
4
5
6
7
/home/mark/Projects/gtkmmsandbox/src/main-window.cc:29:   instantiated from here

/usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:84: error: no match for call to ‘(sigc::bound_mem_functor0<void, Main_Window>) (const int&)’

/usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1786: note: candidates are: T_return sigc::bound_mem_functor0<T_return, T_obj>::operator()() const [with T_return = void, T_obj = Main_Window]

/usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:84: error: return-statement with a value, in function returning 'void'

There's some stuff from slot.h above that, but those only state where some stuff is being instantiated from, within the library.

I have no idea what I've done wrong. Can anyone help me out?
Ok, I got very lucky and found an answer to this buried pretty deep on google after several hours of additional searching.

I needed to make Main_Window::about_hide() accept an int, as GTKmm expects to pass an int from the signal to the handler, which is useful for determining what to do when the button is clicked... that is if it's a regular Dialog or similar, where there may be multiple buttons for the user to click. With an AboutDialog, we still need to accept the int, but we can just ignore it.
Last edited on
closed account (S6k9GNh0)
LupusNoctu, almost all projects that use GTKmm are open source. Just google for it. Also, GTK is mainly used in the Linux arena (not Windows) since Xorg is the only thing it supports natively.

May I suggest something I worked on for a very short amount of time: http://www.mangler.org/

Also, I'd like to add that because GTKmm is heavily based on the C API, it doesn't give a very objective view like some other APIs and therefor tends to be a little bit more difficult to work with on the beginner part. I'm not going to suggest a seperate library nor do I recommend that you do switch, just be aware of it.
Last edited on
Thanks for the reply, computerquip.

Yup. I am aware of that. lol. It was one of the first things I read while I was deciding if I wanted to use GTK+, GTKmm (which from what I understand is actually just a C++ wrapper for GTK+), or QT (would have been my last resort since I prefer GNOME over KDE). Also, if I'm not mistaken, Xorg doesn't "support" GTK, rather GTK is built on Xorg. I recall reading that somewhere. And I do know for a fact that GTK CAN be used in Windows. Your users just need to have the GTK Windows runtimes installed. This is how Pidgin is run in Windows.

I know that GTKmm is for linux/unix, and I am using Ubuntu, which is a large part of why I'm using GTKmm, and why I posted this thread in the Unix/Linux forums here. lol. I swore off of microsoft anything long ago. The closest I come to having anything from microsoft on my system is WINE so I can play World of Warcraft and Starcraft II.

Thanks for the recommendation for Mangler. I've been using that for a long while now. I just never knew it used GTKmm. LOL. I'll go grab the source package. Who knows, maybe I'll be able to contribute something. Perhaps a fix for the crashes that seem to happen about every hour or so. :)

Also, I discovered LostIRC last night as well. Anyone else looking for a program to study, this seems to be a decent one.
Topic archived. No new replies allowed.