Re: GtkButtons and RUN_FIRST/RUN_LAST
- From: Owen Taylor <otaylor redhat com>
- To: Tim Janik <timj gtk org>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: Re: GtkButtons and RUN_FIRST/RUN_LAST
- Date: 26 Oct 2001 16:50:53 -0400
Tim Janik <timj gtk org> writes:
> 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?
::clicked is notification that the button was activated. For GtkButton
it does nothing.
For GtkToggleButton and descendents, there is a default handler for
this which updates the state of the widget. If you want notification
on the state of the widget, you should connect to the ::toggled
signal which is notification of a change to the state.
Connecting to ::clicked to get notification of the change is as
conceptually broken as connecting to ::button_release_event.
> 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.
Well, if this was really a compelling reason, then there would be
a much more compelling reason to make all event signals RUN_FIRST,
since they update widget internal state in much more complex ways
than clicked.
> so, is there anything holding off restauration to the original behaviour?
Well, if you want to do proper model-view-controller with GtkToggleButton,
then you only want to change the state of the togglebutton in response
to changes in the model, not because the user clicked on the
toggle button. Clicking on the togglebutton should call a method
on the model to toggle the model.
In order to do this with RUN_FIRST, what you have to do is
connect to ::toggled (or ::clicked) and change the state back.
Which is highly gross.
While I admit we may have to change this back to keep backwards
compatibility, would agree that ::clicked _should_ be RUN_LAST?
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]