Block a signal for a hierarchy of widget

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Block a signal for a hierarchy of widget

Emmanuel Pacaud-3
Hi,

Is there a way to unblock/block the emission of signals for a hierarchy
of widgets ?

The reason I'm asking is because of this sort of code I'm using:

https://github.com/AravisProject/aravis/blob/master/viewer/arvviewer.c#L588

It is not very convenient and error prone to register every connected
signals and block/unblock them when one want to update some widgets
programmatically.

        Cheers,

                Emmanuel.

_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Block a signal for a hierarchy of widget

Paul Davis
This normally means that you're not using appropriate model-view-controller design.

On Wed, Apr 19, 2017 at 2:19 PM, Emmanuel Pacaud <[hidden email]> wrote:
Hi,

Is there a way to unblock/block the emission of signals for a hierarchy of widgets ?

The reason I'm asking is because of this sort of code I'm using:

https://github.com/AravisProject/aravis/blob/master/viewer/arvviewer.c#L588

It is not very convenient and error prone to register every connected signals and block/unblock them when one want to update some widgets programmatically.

        Cheers,

                Emmanuel.

_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list


_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Block a signal for a hierarchy of widget

Emmanuel Pacaud-3
Hi Paul,

Le mer. 19 avril 2017 à 20:57, Paul Davis <[hidden email]>
a écrit :
> This normally means that you're not using appropriate
> model-view-controller design.

Could you elaborate a bit ? I fail to see where the design of my
application could solve this issue I have with the use of Gtk.

        Cheers,

                Emmanuel.

>
> On Wed, Apr 19, 2017 at 2:19 PM, Emmanuel Pacaud <[hidden email]>
> wrote:
>> Hi,
>>
>> Is there a way to unblock/block the emission of signals for a
>> hierarchy of widgets ?
>>
>> The reason I'm asking is because of this sort of code I'm using:
>>
>> https://github.com/AravisProject/aravis/blob/master/viewer/arvviewer.c#L588
>>
>> It is not very convenient and error prone to register every
>> connected signals and block/unblock them when one want to update
>> some widgets programmatically.
>>
>>         Cheers,
>>
>>                 Emmanuel.
>>
>> _______________________________________________
>> gtk-list mailing list
>> [hidden email]
>> https://mail.gnome.org/mailman/listinfo/gtk-list
>

_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Block a signal for a hierarchy of widget

Paul Davis
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:
Hi Paul,

Le mer. 19 avril 2017 à 20:57, Paul Davis <[hidden email]> a écrit :
This normally means that you're not using appropriate model-view-controller design.

Could you elaborate a bit ? I fail to see where the design of my application could solve this issue I have with the use of Gtk.

        Cheers,

                Emmanuel.


On Wed, Apr 19, 2017 at 2:19 PM, Emmanuel Pacaud <[hidden email]> wrote:
Hi,

Is there a way to unblock/block the emission of signals for a hierarchy of widgets ?

The reason I'm asking is because of this sort of code I'm using:

https://github.com/AravisProject/aravis/blob/master/viewer/arvviewer.c#L588

It is not very convenient and error prone to register every connected signals and block/unblock them when one want to update some widgets programmatically.

        Cheers,

                Emmanuel.

_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list




_______________________________________________
gtk-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-list
Loading...