Re: GtkButtons and RUN_FIRST/RUN_LAST

[Tim Janik <timj gtk org>]

On 26 Oct 2001, Owen Taylor wrote:

> Tim Janik <timj gtk org> writes:
> 
> > On Wed, 24 Oct 2001, Manish Singh wrote:
> > 
> > > The change:
> > > 
> > > 2001-10-18  Havoc Pennington  <hp redhat com>
> > > 
> > >         * gtk/gtkbutton.c (gtk_button_class_init): Change button signals
> > >         to GTK_RUN_LAST, #50239
> > > 
> > > broke GtkRadioButton clicked signal behavior.
> > 
> > eek, this change looks "highly dubious to me", to say the least.
> > and i remember no dicussion pointing out why this should be done,
> > or an examination of expected breakage. in fact, i expect this
> > to break many more user connections, we can't simply toggle
> > emission stages at will.
> > 
> > havoc, could you please provide rationale for this and tell
> > me what dicussion i missed pointing to this change?
> > and even then, we probably need to change things back
> > to maintain the lots of gtkbutton connections out there.
>  
> This was done at my approval, so yell at me rather than Havoc.

> This has been in the GTK+ bug tracker for a long time, and has come up
> on IRC too. I don't know if there has been discussion on this list. It
> was my (wrong) opinion that this wouldn't affect application code, and
> we certainly have the policy that all signals should be RUN_LAST
> unless there is compelling reason otherwise.

was this the only rationale, or is there some more reasoning to come?

if so, a compelling reason would be, to update a widget's state before
arbitrary user code is being run, which is the case for the button handlers.

so, is there anything holding off restauration to the original behaviour?

> 
>                                         Owen

---
ciaoTJ