let's take the example of a button. the button may serve one or both of two purposes:
1) to provide a target for the user to operate on in order to change the state of some part of the "model" within the program (e.g. the state of some variable) - for example, by clicking/pressing it
2) to indicate the current state of the "model" (e.g. a variable)
if the button serves both purposes, then its visual state should change whenever the model changes. other aspects of the program should care about the state of the model, not the button's state.
GTK makes this tricky because it tends to encourage you to use the button state as the model state (i.e. when checking if the user has "set X to true", you tend to check whether the button is pressed or not, rather than whether some independent value is true or not).
so there are now two possible designs:
a) the state of the button IS the "model" state
b) the button is merely a view and a controller for the "model" state (i.e. a variable somewhere)
if (a) is true, then changing the state of the button, whether done by the user or programatically because of some internal logic, results in a change in the model state. anything interested in the model state will have connected to the button signals, and will want to know about this change. blocking the signal implies that you are trying to hide a change in the state of the model from other objects/methods who have stated their interest in knowing when it changes - this can hardly be a good thing.
if (b) is true, then things interested in the model state will ignore the button state itself, and focus on notifications about changes in the model state (e.g. some other variable)
On Thu, Apr 20, 2017 at 7:21 AM, Emmanuel Pacaud <[hidden email]> wrote: