Re: [gtk-list] Re: [ repeat message] toggle button: clicked == toggled, and vice versa

[Paul Barton-Davis <pbd op net>]

>> All I really want is a way to set a button to be "active" without
>> making it appear that there was user interaction.
>> 
>> The error, I think, is that toggle buttons have 2 signals, but anytime
>> you generate 1, you also generate the other. It seemed to me from
>> reading the docs that one could connect to "toggled" instead of
>> "clicked", and would then *every* change to the button
>> state. Alternatively, one could connect to "clicked", and see only
>> those changes caused by a mouse click.
>
>You'll need to explain a bit more about what you are trying to
>do - to justify _why_ you want this change, instead of explaining
>_what_ you want.

Claim 1:
The buttons in GTK cannot currently be set programmatically without
invoking the callbacks attached to the signals sent when user
interaction occurs.

Claim 2:
Many other GUI toolkits have buttons whose state can be set by a
program in a way that does not make it appear that there was any user
interaction (i.e. callbacks associated with user interaction will not
be called).

Claim 3:
This is a useful feature.

>Several common approaches have been suggested as to how people
>typically deal with the problem - blocking handlers, using a

blocking handlers can only be done (currently) if you know the handler
ID or data pointer. this is a violation of the encapsulation that GTK
signals offer. the idea that a button knows who has connected to it
seems totally wrong to me.

>global boolean, 

this means that every callback for the signal has to know that this
button can sometimes be set programmatically, and that it (the
callback) must always check the boolean. 

in short, it has to know that its really a different kind of button.
i am all for deriving a new class, but what to call it, when it has
the kind of behaviour i would have expected from a ToggleButton anyway?
 
>		 connecting your signal handlers after you set
>up the initial state.

not much use. the point here is to deal with situations where some
event source other than the X input devices causes a change in the
button state; these can happen at any time.

>Any change to make "clicked" not be emitted via
>gtk_toggle_button_set_active() could potentially break existing
>code, so would have to be approached with caution.

I understand this. That's why I was really asking if we could write
and merge gtk_signal_block_handlers(). That way, I could write code
that did:

     gtk_signal_block_handlers (GTK_WIDGET(toggleButton), "clicked");
     gtk_toggle_button_set_active (GTK_BUTTON(toggleButton)
     gtk_signal_unblock_handlers (GTK_WIDGET(toggleButton), "clicked");

and everything would be just fine (albeit a gross kludge :)

--p