Re: Deprecating gtk_signal_* gtk_object_*

[Owen Taylor <otaylor redhat com>]

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.
 
> > 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().

> 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.

Regards,
                                        Owen