Gtk--: RFyC: gtk-- experiences (1 year of usage)

[Christof Petig <christof petig wtal de>]

Hello,

I've put some of my experiences into a html file and would like to
receive your comments about this. Perhaps one of the gurus has a better
proposal for some problems at hand.

   Christof

PS: RFyC should mean Request For your Commnents.
PPS: Of course you might take this document to your Gtk-- WebSite. It
will become part of glade-- at cvs.gnome.org (subdirectory docs).

Title: Some assorted Gtk-- experiences

$Id: gtkmmtips.html,v 1.1 1999/01/26 12:43:50 christof Exp $

Some assorted Gtk-- experiences

• Never try to copy a Widget. This might change in future revisions of gtk-- (>0.10). But up to now it is lethal. So avoid:

    widget=other_widget;
and
    vector<Gtk_Widget>.push_back(widget);.
Havoc explains in detail what is going wrong. Instead use vector<Gtk_Widget*>.push_back(new Gtk_Widget());.

I have been told (Tero, Sep 98) that vector<auto_ptr<Gtk_Widget>> should provide even more enhanced functionality but I haven't found any docu about these new gtk-- features, yet!
 

• Deleting a widget tree has issues. So far calling hide() and then deleting the widget should be safe for windows/dialogs. But this is only safe for widgets which are not contained within another widget (e.g. a Box). Gtk-- has no gtk_container_remove equivalent, yet.

You might work around deleting widgets by hiding them and reusing them (ugh!)
 

• You cannot delete a Widget while processing a callback from it. For me the following works:

class Dialog1 : public Dialog1_Glade
{       static void close_window(Dialog1 *dlg);
public:
        Dialog1();
};

void Dialog1::close_window(Dialog1 *dlg)
{  dlg->hide();
   dlg->destroy();
//   delete dlg; is not possible
}

Dialog1::Dialog1()
{  connect_to_function(button1->clicked,&close_window,this);
}
be warned though that this opens a memory leak since dlg can't be deleted (you might delete it within an idle call - this is a good idea, I should give it a try).
 

• Documentation is one of gtk--'s weaknesses. The perceps generated html files are a good source to look which methods are available. A look at either glade or testgtk inform you about the features of a specific widget type. Since the gtkmmtest program is not yet available I recommend looking into the testgtk source for some tricks. gtk/gtkenums.h provides you with the choices available for enumerated arguments.

Adding documentation to the gen_h files is not difficult. If you want to help this would be a good point to start with even little expertise.
 
• I can't get Paned windows to work. If you have any working example with gtkmm please send me a copy. This would add Paned support to glade--, immediately!

 
• There seems to be no standard way of getting the number of lines within a List/CList. Of course there is a gtk interface.

 
• Refreshing your windows takes place within idle time. To accomplish this while you do computive work it requires a resync. The following code does the latter:

Gtk_Main *Main=Gtk_Main::instance();
while (Main->events_pending()) Main->iteration();
 
• Classes that use signals have to derive from Gtk_Signal_Base (Havoc). I promised to insert this into the documentation, but didn't yet have the time to figure out where it belongs and whether it's already there.

Appendix: Original Quotes

Havoc Pennington about the push_back problem

The bug is that the copy constructor should be private. There's no way you
should be able to do this. It's *incredibly* inefficient - that's a large
object you're copying. With much hassle and Gtk changes it could maybe be
made to work but you don't want to do it. You are probably getting a
segfault because the default copy constructor is just copying all the
internal pointers from one object to the other, and then one of the
objects (thinking it's the only object using the pointer) deletes one of
the pointers. Probably when the temporary's destructor is called if
nothing else.

There's no way to write C++ without pointers, especially with Gtk
underneath. If you don't want to use them and don't care much about
efficiency, you should probably choose a higher level language like Guile,
Perl, etc.

Tero about the push_back problem

Christof Petig <christof.petig@wtal.de> writes:
> here's a really strange bug:
> using the following statements (window1.cc:14) I get an SIGSEGV:
>
> vector <Gtk_MenuItem>  optionmenu1_menuitems;
>
>         optionmenu1_menuitems.push_back(Gtk_MenuItem("one"));
>         optionmenu1_menuitems.push_back(Gtk_MenuItem("three"));
>         optionmenu1_menuitems.push_back(Gtk_MenuItem("nine"));
>         optionmenu1_menuitems.push_back(Gtk_MenuItem("twentyseven"));
>
> As I understand the current C++ standards and implementations this would
> correspond to
> 1 - create an temporary MenuItem
> 2 - copy it into the vector
> 3 - destruct the temporary

between steps 2 and 3, there's two gtk-- objects available - should
there be two widgets in the screen or not ? :) Also which instance
gets to override the virtual functions or receive signals? (when gtk
widget's virtual function is called, gtk-- uses gtk_object_get_data to
get the this pointer of "current" C++ object - copying the widget
changes that this pointer... :)

Hmm... I was surpriced the compiler did not give compile time error on
the code. Guess we should provide copy constructor which increases
reference count on the gtk+ object or (preferably) make the copy
constructor private and thus disallowing copying of widgets. Another
thing to look is all pointer members inside widgets and places where
this pointer is passed to gtk. (Gtk_Object::Gtk_Object at least passes
this pointer to the gtk and should be dealt in the copying
operation...)

> Though I feel this is a kind of "don't do that" TM, I would really like
> it working. Since using pointers is tiring.

It might be possible to make copying gtk-- widgets work - but many
things needs to be fixed before that can safely happen. (until that we
should really disallow copying widgets) If proper semantics for the
copying operation can be found, maybe that feature can be implemented,
but... Better use vector<auto_ptr<Gtk_Widget> > instead of
vector<Gtk_Widget> currently. (main problem with using pointers is
destructing the widgets when the vector dies or when the widget is
removed from the vector..)

(oh, I never tried if auto_ptr<> works any better - but it might have chance
of working alittle better :)

Havoc about signal connection

On Mon, 2 Nov 1998, Christof Petig wrote:
>
> while compiling a really simple program with gtkmm signals (current CVS
> and older versions checked) I ran into the strange requirement to have
> insert_connection in each class connecting to signals.
>
> This can't be right!
>

Classes that use signals have to derive from Gtk_Signal_Base.