Re: Deprecating gtk_signal_* gtk_object_*

[Tim Janik <timj gtk org>]

On 26 Oct 2001, Owen Taylor wrote:

> 
> Tim Janik <timj gtk org> writes:
> 
> > On 20 Oct 2001, Owen Taylor wrote:
> > 
> > > 
> > > Based on comments in the documentation, #61942 calls for
> > > for marking virtually all of gtkobject.h GTK_DISABLE_DEPRECATED.
> > > (Except for gtk_object_sink(, gtk_object_destroy())
> > 
> > i assume you mean ::destroy, as gtk_object_destroy() is easily
> > deprecated by gtk_widget_destroy.
> 
> How do you destroy a GtkAdjustment then? Since gtk_object_destroy 
> corresponds to functionality in GtkObject - sink and ::destroy,
> gtk_object_destroy() is the right name.

oops. hm, GtkData::disconnect is gone right? that would have been the
right place for "destruction" of non-widget gtk objects.
i need to insist on "destroy" in itself being a broken name for
our current concepts though ;)

> > > If we do that, we should presumably correspondingly deprecate
> > > all of gtksignal.h.
> > > 
> > >  - Pro: People would be better off not using this stuff in
> > >    new code, and deprecating it hopefully will hopefully
> > >    provide protection against people using it in example
> > >    code.
> > > 
> > >  - Con: Making code GTK_DISABLE_DEPRECATED clean becomes
> > >    even more of a pain and people may just not bother.
> > > 
> > > In balance, I think I favor doing this, but I'd like
> > > other opinions.
> > 
> > i think the outcome will be somewhat odd. you're not supposed
> > to use GtkObject e.g. to ref widgets or set data on them, otoh,
> > you have to use it for sinking, and ::destroy and need extra
> > casting for that.
> 
> Err, GtkObject is a base class that adds sinking and destruction,
> hence if you use these capabilities you cast to GtkObject.
> 
> Though, now you mention it, we do need to deprecate:
> 
>  gtk_widget_destroy(), gtk_widget_ref(), gtk_widget_unref() 
> 
> as well. It doesn't make much sense to deprecate gtk_object_ref()
> and leave gtk_widget_ref().

it doesn't make much sense to deprecate those.
yes, they are wrappers for GObject/GtkObject functions, but
extremely handy ones. since most widget pointers are being
kept as GtkWidget*, this is just increasing programmer burden
at 0 benefit, since they'll now have to constantly write:

gtk_object_destroy (GTK_OBJECT (widget));
g_object_ref (G_OBJECT (widget));
g_object_unref (G_OBJECT (widget));

(ok, we're kind enough to take gpointer in _ref/_unref of gobject,
but _ref/_unref for widgets were convenience for years, deprecating
them now is just pure annoyance)

> > imho, if we decide to deprecate GtkObject and put the burden on
> > third-party authors, then we also need to walk the full path, i.e.:
> > 
> > - deprecate all of gtk_object_* and ::destroy
> > - provide gtk_widget_sink()
> > - deprecate gtk_widget_destroy()
> > - provide gtk_widget_break_refs() and ::break-refs
> > - emit GtkObject::destroy from GtkWidget::break-refs for
> >   backward compat
> > 
> > so, as a result, the broken ::destroy conotations are
> > gone except for compat, and people don't need to worry
> > about GtkObject in any code.
> > of course, compat emitting ::destroy from ::break-refs is
> > another performance hit to take.
> 
> I don't see any reason to deprecate GtkObject itself, as you suggest,
> I just want to (and already did) deprecate the parts of it that are
> mere wrappers around GObject.

erk. good, that we could discuss every aspect beforehand.

> 
> Regards,
>                                         Owen

---
ciaoTJ