Gtk::Switch problem, not being able to handle the signal state_set

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Gtk::Switch problem, not being able to handle the signal state_set

Carlos Gomez
Hi all,


I have been using gtkmm for years and never had a serious problem, but
now I am trying to use Gtk::Switch with this code:

m_switch.signal_state_set().connect( []( bool b ){ std::cerr << "Caught
state_set" << std::endl; return true;} );


and I cannot see "Caught state_set" on my console. If I change the
lambda to be a void return one the compiler avoids that, so I know the
signature is the right. I am developing on Ubuntu 16.04 and rapsbian

and I have the same problem in both.

Packages I am using are

raspbian:

libgtkmm-3.0-dev:armhf  version 3.22.0-1

Ubuntu:

libgtkmm-3.0-dev:amd64 version 3.18.0-1


I can solve my problem connecting to signal_changed of property_active
or property_state, but I'd like to know if there is a problem with
signal_state_set or if I am doing something wrong.


Cheers,


Carlos.

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

Re: Gtk::Switch problem, not being able to handle the signal state_set

Gtkmm mailing list
from the doc:

"The signal_state_set() signal on GtkSwitch is emitted to change the underlying state. It is emitted when the user changes the switch position. The default handler keeps the state in sync with the Gtk::Switch::property_active() property"

that is: the point of this signal is to control how the state changes, not listen for said changes. if you override that default handler, it probably won't do what you expect. also, you're not connecting before that default, hence why you don't see any printout.

checking for changes on the property as you proposed is correct, I think.


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

Re: Gtk::Switch problem, not being able to handle the signal state_set

Carlos Gomez
Hi Daniel,


Thanks for your answer, but the thing which is driving me crazy is this
sentence "It is emitted when the user changes the switch position", but
if I (the user) change the switch position the signal is not emitted.
I'll try to dig deeper in the sources, at least using the properties I
have what I need.

Cheers.

On 28/05/2019 12:35, Daniel Boles via gtkmm-list wrote:
> It is emitted when the user changes the switch position
_______________________________________________
gtkmm-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk::Switch problem, not being able to handle the signal state_set

Gtkmm mailing list
*your* signal handler might not fire, because you're connecting after the default handler (vfunc), which probably returns true to block any further handlers.

if you pass false for the after argument of Signal.connect(), your handler will probably get called.

but it still won't be the right signal to use to simply observe when the state changes, because this signal is intended for changing the implementation of how/when state changes are applied, not observing the state.


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

Re: Gtk::Switch problem, not being able to handle the signal state_set

Carlos Gomez

That's the reason, now my signal handler is fired, but I think you are right and I am going to handle the change of the property, that is what I really need.

Thank you very much.

On 28/05/2019 14:28, Daniel Boles via gtkmm-list wrote:
*your* signal handler might not fire, because you're connecting after the default handler (vfunc), which probably returns true to block any further handlers.

if you pass false for the after argument of Signal.connect(), your handler will probably get called.

but it still won't be the right signal to use to simply observe when the state changes, because this signal is intended for changing the implementation of how/when state changes are applied, not observing the state.


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

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

Re: Gtk::Switch problem, not being able to handle the signal state_set

Gtkmm mailing list
You're welcome!

I hadn't consciously realised GtkSwitch had both :active and :state to be honest. The latter is for delayed state changes, so if you just need a simple switch, you should be able to leave the ::state-set handler alone and observe changes on either of those properties, because they should change in lockstep.


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