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

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

Hi!

The only thing you and M.C. are mistaken about is that _if_ we keep
the name manage() in gstmm, only those users will be confused that
suddenly _try_ to write something like

Gtk::RefPtr<Gtk::Label> = manage(new Gtk::Label);

It is my believe that they will notice very soon that what they
are trying to do may be perfectly legal in gstmm but is simply not
possible in gtkmm because
a) there is no Gtk::RefPtr<> and
b) it is not possible to implement without changing the gtk+
   way of handling container destruction.

Users coming from gtkmm and starting to use gstmm like they are
using gtkmm (that is without the Gst::RefPtr<>) won't notice any
difference.

Confused? :-)

Regards,

  Martin


Am 03.10.2002 18:08 schrieb(en) "Butler, Gerald":
> > -----Original Message-----
> > From:	Paul Davis [SMTP:pbd op net]
> > Sent:	Thursday, October 03, 2002 11:48 AM
> > To:	Butler, Gerald
> > Cc:	'Carl Nygard'; 'MHL Schulze t-online de'; gtkmm-list
> > Subject:	Re: [Re:[[gtkmm] technical question: GTKMM_LIFECYCLE]
> >
> > >> "petitioning the GTK+ crowd to use gtk_object_unref()
> > >> instead of gtk_widget_destroy() in gtk_container_destroy(). then
> we'd
> >
> 	<SNIP>
>
> > >lasts the longest. If so, isn't this semantically different from the
> > purpose
> > >of "manage" which is to absolutely surrender the lifetime of the
> object to
> > the
> > >lifetime of the container?
> >
> > yes, that is the purpose of "manage" as currently implemented, but its
> > predicated on the way GTK+ containers work.
> >
> > the central question:
> >
> >    Gtk::Foo *foo = new Foo;
> >    Gtk::Container *bar = new Container;
> >
> >    bar->add (foo);
> >    ...
> >    delete bar;
> >
> >    // is foo is still a valid C++ object a this point?
> >
> > in many common GUI applications, there is no reason for foo to be
> > valid any longer - adding foo to bar was intended to allow bar to
> > manage its lifecycle, hence:
> >
> >        bar->add (manage (foo));
> >
> > works to make this explicit. for many people and situations, this is
> > exactly what you want to happen.
> >
> > however, there are other cases where its not. in those cases, you want
> > to the lifetime of foo to be determined by the longest-lived reference
> > to it. if thats bar, fine. but perhaps its something else.
> >
> > with GTK+'s current model, there is no way to do this. this isn't a
> > requirement of GObject, the underlying C object, its a design decision
> > implemented by GTK+. other GObject-using APIs can make a different
> > design decision that supports the "longest-lived reference" model and
> > GObject will support that too. but gtkmm doesn't because GTK+ doesn't.
> >
> > i believe that GTK+ made a mistake in this design decision, but its a
> > mistake that i have to admit i have never been affected by in any way.
> >
> 	Aha! Now I think I understand the argument. Please allow me to
> summarize.
>
> 	1) M.C. Says, GtkMM does things exactly correctly because:
>
> 		a. It has default C++ automatic memory management on the
> stack
> 		b. It has default C++ dynamic memory management on the
> heap
> 		c. It supports the Gtk dynamic "manage" memory model
> 		d. All is well and good!!!
>
> 	2) The GstMM developers say, "No there's a problem":
>
> 		a. We want to do something *like* manage, but not exactly
> 		b. The way we want to do it is different then the way
> Gtk, and
> as a result GtkMM, does it
> 		c. We need our new way, because our underlying GStreamer
> classes, that GstMM wraps, implement it this way - unlike Gtk
> 		d. We want to use "manage" to do what we want, but we
> want it
> to be semantically different from what GtkMM::manage does
> 		e. That's OK because, we are wrapping "GStreamer" which
> is
> based off "GObject" whereas GtkMM wraps "Gtk"
> 		 
> 	3) M.C. says, "Oh No! We can't have *manage* have two completely
> different semantic meanings in C++ wrappers for Gtk related stuff. It
> will be
> too confusing to the end users."
>
> 	4) The GstMM developers say, "But we're not Gtk related stuff.
> We're
> GStreamer/GObject related stuff. So, your point is moot."
>
> 	5) Hence, a huge, gaping, monstrous schism between the two sides
> as to
> what is *CORRECT*.
>
>
> 	Does all this summarize correctly? If so, I'd like to add by 2
> cents
> to the discussion. I believe, in my humble opinion, that what the GstMM
> developers want to do, they should do. However, I agree with M.C. that
> calling
> it "manage" would be extremely misleading and confusing to end-users.
>
> 	Saying that Gtk implements it improperly is like saying that the
> definition of a line is incorrect. It's axiomatic. *manage* is, by
> definition,
> absolutely correct in its behaviour. It does *exactly* what it was
> intended to
> do. I really don't see how you can argue that something is wrong, if it
> performs precisely as intended. The best you can say is, there is another
> way
> to think about the problem.
>
> 	I think having something *like* manage under GstMM is the best
> solution. Perhaps it should be called "container_reference".
>
> 	Thank You for this opportunity to give my opinion.