Re: How can I port this gtk construct to gtkmm?

[Jef Driesen <jefdriesen hotmail com>]

Jonathon Jongsma wrote:
> On 3/20/07, Jef Driesen <jefdriesen hotmail com> wrote:
> > I am writing my first gtkmm application (actually my first GUI
> > application). To get familiar with the toolkit (both gtk and gtkmm), I
> > studied the code of some existing applications. And in one of those
> > applications I found a construct that I would like to use in my own
> > application, but I don't know how to port the gtk code to gtkmm.
> >
> > The main application contains a treeview and a secondary dialog is used
> > to edit the treeview entries. But if you try to edit an entry that is
> > already "open", the existing dialog is activated instead of creating a
> > new one (see code snippet below). How can I do this in C++?
> >
> > And how do I automatically destroy the dialog after clicking the (close)
> > button?
> >
> > [code removed]
>
> Well, first of all, you'd probably want to replace the g_hash_table
> stuff with a std::map<> type.  You might even want to store the Dialog
> pointer in a smart pointer so that when you remove the item from the
> std::map, the Dialog is deleted automatically.  Something like this:
>
> std::map<myobject*, boost::shared_ptr<Gtk::Dialog> > dialogs;
>
> // when you need to add a new dialog to the cache:
> dialogs[obj] = boost::shared_ptr<Gtk::Dialog>(new Gtk::Dialog());
>
> // then in a signal handler: this should remove the item from the map and
> // automatically free the dialog you allocated earlier since you're
> using a smart pointer
> dialogs.erase (obj);
>
> The signal handling should be pretty similar to the existing code, but
> would use libsigc++ type signal connections instead of the
> g_signal_connect() stuff.  for example:
>    g_signal_connect (close_button,
>             "clicked",
>             G_CALLBACK (myobject_dialog_close_clicked_cb),
>             dialog);
> would become something like:
> close_button.signal_clicked ().connect
> (sigc::ptr_fun(myobject_dialog_close_clicked_cb));
>
> But it might be easier to just create a new Dialog class that inherits
> from Gtk::Dialog and provide implementations for its virtual signal
> handler methods (such as on_delete_event(), etc) instead of manually
> connecting to the signals.
> Hope that helps. (note that I haven't tested any of the code snippets I posted)

Actually my problem is not how to connect signals or use C++ features 
like the std::map for instance.

The first problem was that I was trying to incorporate the functionality 
of the myobject_dialog_new function (construction of the widget and 
maintaining the cache) inside the constructor of the dialog class. And I 
could not come up with a way to return an existing dialog from the 
cache, because the C++ constructor does not return any value. Moving the 
cache outside the constructor or even the dialog class (like you did), 
will solve that problem I think.

And the second was the automatic destruction of the dialog without the 
need to keep a pointer to it somewhere. Trying to do the same thing in 
C++ resulted either in a memory leak or immediate destruction of the 
dialog (when its variable goes out of scope).