Re: [gtk-list] Re: [ repeat message] toggle button: clicked == toggled, and vice versa
- From: Bernhard Herzog <herzog online de>
- To: gtk-list redhat com
- Subject: Re: [gtk-list] Re: [ repeat message] toggle button: clicked == toggled, and vice versa
- Date: 18 Jan 2000 18:47:33 +0100
Owen Taylor <otaylor@redhat.com> writes:
> Paul Barton-Davis <pbd@op.net> writes:
[...]
> > All I really want is a way to set a button to be "active" without
> > making it appear that there was user interaction.
[...]
> 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.
>
> Several common approaches have been suggested as to how people
> typically deal with the problem - blocking handlers, using a
> global boolean, connecting your signal handlers after you set
> up the initial state.
While I'm not the original poster, I had a similar problem in Sketch's
toolbox. Blocking the handlers works, but is a bit inconvenient, IMO.
> It seems that you aren't satisfied by these approaches because
> you want to do something that is more generic and allow other
> people to connect to your signals as well. But you haven't
> really given enough context to allow us to figure out what
> sort of thing you are trying to do.
The situation in Sketch is as follows: The toolbox is basically a bunch
of toggle buttons, one for each tool. At any one time, exactly one of
the tools is active and the associated button has look pressed down.
The state, i.e. which tool is active, is kept in the application and the
toolbox is merely view and controller for this state, so I have to be
able to set the state of a toggle button without triggering the attached
signal handlers to make the view reflect the state. This is especially
important because the toolbox is not the only way to change the tool,
you can also use the keyboard.
So, what it boils down to is that not being able to modify the state of
widgets without triggering the 'changed' signals that are normally
triggered *as response to user input* makes a model/view/controller
architecture hard to implement becasue you have to be able to update the
view especially when there are several views/controllers for the same
model.
I could perhaps have used radiobuttons instead of toggle buttons in my
particular example, but the same problem would arise if the toggle
button is the view/controller for a boolean aspect of the application's
state.
> 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 haven't looked at that part of the code yet, but IMO a good solution
would be to split gtk_toggle_button_set_active() into two functions,
gtk_toggle_button_set_active_silently() that just modifies the state of
the widget and gtk_toggle_button_set_active() that calls the *_silently
variant and then emits the signals.
--
Bernhard Herzog | Sketch, a drawing program for Unix
herzog@online.de | http://sketch.sourceforge.net/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]