Re: [Re: [Re: [Re: [Re: [Re: [[gtkmm] technical question: GTKMM_LIFECYCLE]]]]]]

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

Hi!

Thanks Murray, I liked this response much more than your previous ones
because you clearly say where you think I'm wrong and I don't have to
guess. Also it makes me see where we simply didn't understand each other.

1) Test code that doesn't work with gtkmm and that won't ever work with
   gtkmm. Yet it seems to be what you proposed earlier:

#include <gtkmm/main.h>
#include <gtkmm/box.h>
#include <gtkmm/label.h>
#include <boost/shared_ptr.h>

Gtk::HBox my_final_box; // This box could reside anywhere in the project.

void test1()
{
  // don't call manage. Otherwise my_label will be destroyed when
  // the first all to test2 ends.
  boost::shared_ptr<Gtk::Label> my_label = new Gtk::Label("test1");

  test2(my_label); // first call to test2. Works smoothlessly.
                   // If we called manage() above, the C instance
                   // and thus also our C++ wrapper would be dead
                   // now because the box we fed with my_label
                   // has been destroyed (out of scope).

  test2(my_label); // second call to test2. Also works.

  // Now I add *my_label to my_final_box.
  my_final_box.push_back(*my_label);

} // Peng! function ends, my_label is out of scope, C++ wrapper is
  // deleted => C instance is deleted (and removed from the box).
  // This is not what I expect as a user: my_final_box references
  // *my_label. Why then should *my_label die? Or do you expect me
  // to keep an extra list of shared_ptr<> for each box?

void test2(const boost::shared_ptr<Gtk::Label>& my_label)
{
  Gtk::HBox my_box;
  my_box.push_back(*my_label);

  /* Do something with the box. Show it in a dialog or whatever. */
}

int main()
{
  Gtk::Main(argc,argv);
  test1();
  return 0;
}


2) I do know what happens if an object is not manage()ed. I didn't
   fully understand it first because I didn't see that ref_count >= 1
   is always guaranteed until the C++ wrapper dies because the
   initial reference is not removed until then. You told me ages ago.
   The C++ wrapper on the other hand only dies when it gets out of
   scope or when the user calls delete on it. I saw this right from
   the beginning.
   With my question that I've repeated four time I was trying to make
   you see that therefore it can't work to rely on the glib reference
   counter with unmanage()ed objects: at least the C++ wrapper won't
   ever get deleted. You know this but you didn't allow me to draw
   the conclusion from it that the example code in 1) can't work
   satisfactory. I hope this is clear now.


3) Concerning gstmm:
  - No, Gst::Object doesn't derive from Gtk::Object. It is based on
    Gtk::Object in that I copied most of the lifecycle code.
    Now I see where I wasn't using the language correctly :)
  - I want the Gst::Object wrapper to allow for a maximum of
    flexibility. I.e. there should be the possibility to not
    manage() an object so that the C++ instance won't be deleted
    in an unreference() like in gtkmm. This is possible with GtkObject,
    GstObject but not with GObject because of the missing "floating state"
    which was the reason why Glib::RefPtr<> was invented, historically.

Am 01.10.2002 00:18 schrieb(en) Murray Cumming:
> By the way, I really disagree with your re-implementation of the manage()
> system in Gst::Object because
> 1) manage() is for child widgets and GtkObjects are not widgets. This
> would
> confuse the definition of manage().
> 2) You have said that you want manage() to work differntly with
> Gst::Objects
> than it does currently with Gtk::Objects.

  While the second point won't break anything because it will work like in
  gtkmm if you add your objects to one container only and delete the
  container (which is the most common scenario in gtkmm), I will think
  about your first point.
  At the moment I still believe that manage() is meant more abstract and
  simply means "let the lifetime of my object be controlled by a reference
  counting system so that it will be deleted when all references have gone
  (especially the one of the container I fed with my object)".


> > The thing I was mistaken about was the fact that it is non-trivial to
> use
> > Gst::RefPtr<> for gtkmm objects because of GtkButton.
>
> By the way, GtkButton has just been changed (probably only in Gtk+ HEAD)
> so we
> could go back to relying on that side-effect, but I'd prefer to keep the
> fix
> that does things properly instead.

That's nice to hear. How things are properly done is a question
of definition. Do we want the gtk containers on destruction to force
the destruction of our objects or do we want to rely on the fact that
they will get destroyed anyway when the container holds the only
reference. But now I'm repeating myself again. Please just ignore it.

Regards,

  Martin