Re: [gtkmm] "manage" and Glib::RefPtr

[MHL Schulze t-online de (Martin Schulze)]

Am 2002.10.08 00:44 schrieb(en) Christof Petig:
> Just a theoretical question (which might solve some memory managaement 
> problems if possible):
>
> Is it possible to write a manage_ref 'function' which would ...
> - destroy the widget once no RefPtr (or C ref) to it is left
> - not get the widget destroyed once it's container is destroyed but unrefed

This would be possible but not trivial: We already implement
our own destroy() callback for Gtk::Container and prevent destruction
of non-manage()ed widgets there. We could also prevent the destruction
of manage_ref()ed weigets. I already tested that. The problem is that
Gtk::Button with a mnemonic starts with a reference count of two after
construction. This means a child (the mnemonic) holds a strong
reference to its parent (the Gtk::Button). We would have to add some
workaraund code for this or Gtk::Buttons with mnemonics would never
be deleted when manage_ref()ed.

> (unlike manage, IIRC manage does set some gtk+ flag which enables 
> unconditional destruction)

No, manage() does not set some gtk+ flag to enable unconditional
destruction. gtk+ always does unconditional desctruction. We simply
prevent the desctruction by reimplementing the container's destroy
handler removing non-manage()ed widgets before the gtk callback
can destroy them.

> This would allow code like
> { Glib::RefPtr<Gtk::Window> w=manage_ref(new Gtk::Window(...));
>    ...
>   { Glib::RefPtr<Gtk::Label> l=manage_ref(new Gtk::Label("test"));
>     w.add(l);
>   }
>   ...
>   // w leavess the scope
>   // => w gets destroyed, the Label unrefed (and then destroyed)
> }
> and if I understand correctly this would solve the destroy vs. unref problem 
> with widgets. IIRC this would also not force us to use RefPtrs for any 
> function arguments (function arguments outlive the call).

We could not use Glib::RefPtr<> because it doesn't have operator*().
Otherwise I agree.

Regards,

  Martin